VPLEX : Disk marked hardware dead due at SCSI check condition 3/11/0 from storage-array

Cet événement est déclenché lorsque VPLEX effectue une demande de lecture sur la LUN de la baie de stockage sous-jacente et que la baie n’est pas en mesure de traiter les E/S sur ce bloc de la LUN, ce qui déclenche la condition de vérification 3/11/0 (bloc défectueux sur la baie).

• Migration d’extension/de périphérique VPLEX
• Opérations de sauvegarde
• Vérifications d’intégrité de la base de données

Le volume de stockage VPLEX est marqué comme « hardware-dead », mais s’affiche comme étant intègre sur l’interface de la baie de stockage.

Exemple de sortie de la commande CLI ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

La migration d’appareil/d’extension VPLEX (tâche de mobilité) reste bloquée à un certain pourcentage.

Exemple de sortie de la commande CLI ll data-migrations/device-migrations/<device_migration_name>
 

L’hôte voit le stockage VPLEX se déconnecter ou être marqué comme inactif, et le volume de stockage VPLEX est également marqué comme étant en panne critique ou matériel hors service.

Des exemples de données telles qu’elles figurent dans le journal du micrologiciel,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

Les journaux du firmware VPLEX indiquent un accès en continu ou scsi/27 intermittent (vérifier la condition) avec des entrées de code de détection SCSI pour le 11/03/0, ce qui se traduit par «Medium Error - unrecovered read error«

Exemple de sortie tel qu’indiqué dans le journal du firmware lors de l’incident,

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

Pour confirmer ce problème, les éléments suivants seront toujours vrais :
key   = 0x3
asc   =  0x11
ascq = 0x0

Lorsque VPLEX envoie une demande de lecture d’E/S (0x28) à la baie de stockage, la baie n’est pas en mesure de traiter correctement la demande d’E/S et répond avec la condition de vérification 3/11/0 pour « erreur de lecture non restaurée ».

VPLEX tente de lire à partir d’un bloc défectueux sur la baie de stockage et, comme la baie de stockage est incapable de traiter cette E/S, VPLEX marque le stockage comme inactif.

Il ne s’agit pas d’une baie ou d’un code de baie spécifique.

La cause de ce problème est externe à VPLEX et est un problème sur la baie de stockage avec LUN.

La baie de stockage qui envoie la condition de vérification scsi, 3/11/0, à VPLEX doit être examinée par le fournisseur de la baie correspondant. Ce problème est déclenché lorsque la baie n’est pas en mesure de répondre à la demande d’E/S de lecture en raison d’un problème de « lecture non restaurée » sur la baie de stockage.

Le support VNX doit être contacté.

La commande CLI suivante peut être exécutée sur le serveur de gestion VPLEX pour obtenir la liste des 50 unités logiques principales affectées par les conditions de vérification du 11/03/0 :

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


Exemple :

Il s’agit d’un problème de couche en mode bloc sur la baie de stockage qui ne peut être résolu qu’en prenant des mesures sur la baie de stockage elle-même.

Il ne s’agit pas d’un problème VPLEX, mais du VPLEX signalant un symptôme provenant de la baie back-end.

L’utilisation de « storage-volume resurrect --force » n’est pas valide ici.
Cette commande force le volume de stockage inactif à apparaître comme « actif » dans VPLEX, quel que soit son état d’E/S actuel ou les problèmes sur la baie de stockage sous-jacente.
Cette commande force le volume de stockage à revenir en ligne jusqu’à ce que les prochaines E/S échouent sur la baie de stockage sous-jacente.
Lorsque l’hôte demande le même bloc de données qui présente le problème 3/11/0 sur la baie de stockage sous-jacente, le volume de stockage est à nouveau marqué comme inactif.
Il s’agit d’un comportement normal et non d’un problème VPLEX.


La présentation du volume de stockage problématique directement de la baie de stockage à l’hôte (en contournant VPLEX) peut permettre à l’hôte d’utiliser certaines données. Toutefois, cette action présente directement une éventuelle corruption des données à l’hôte. L’hôte continue d’avoir des problèmes de lecture à partir des blocs spécifiques avec le problème de condition de vérification 3/11/0.