VPLEX: Hardware contrassegnato come guasto a causa della condizione di controllo SCSI 3/11/0 dall'array di storage

Questo evento viene attivato quando VPLEX esegue una richiesta di lettura alla LUN dell'array di storage sottostante e l'array non è in grado di gestire l'I/O su tale blocco della LUN, attivando la condizione di controllo 3/11/0 (blocco danneggiato sull'array)

Ciò si verifica comunemente in situazioni con tempi di I/O di lettura intensivi, ad esempio:

• Migrazione di extent/dispositivi VPLEX
• Operazioni di backup
• Controlli di integrità del database

Il volume di storage VPLEX è contrassegnato come "hardware-dead", ma risulta integro nell'interfaccia dell'array di storage.

Esempio di output del comando cli ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

La migrazione di dispositivi/extent VPLEX (lavoro di mobilità) si blocca a una determinata percentuale.

Esempio di output del comando cli ll data-migrations/device-migrations/<device_migration_name>
 

L'host vede lo storage VPLEX andare offline o contrassegnato come inattivo e anche il volume di storage VPLEX viene contrassegnato come guasto critico o come inattivo hardware.

Dati di esempio indicati nel registro del firmware,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

I registri del firmware VPLEX mostrano lo streaming o intermittente SCSI/27 (Check Condition) con le voci del codice di rilevamento SCSI per 3/11/0, che si traduce in "Medium Error - unrecovered read error"

Output di esempio come indicato nel registro del firmware durante l'incidente,

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

A conferma di questo problema, è sempre vero quanto segue:
key   = 0x3
asc   =  0x11
ascq = 0x0

Quando VPLEX invia una richiesta di lettura I/O (0x28) all'array di storage, l'array non è in grado di soddisfare la richiesta di I/O e risponde con la condizione di controllo 3/11/0 per "errore di lettura non ripristinato".

VPLEX tenta di leggere da un blocco danneggiato sull'array di storage e, poiché l'array di storage non è in grado di eseguire la manutenzione di questo I/O, VPLEX contrassegna lo storage come inattivo.

Non si tratta di un array o di un codice di array specifico.

La causa di ciò è esterna a VPLEX ed è un problema sull'array di storage con LUN.

L'array di storage che invia la condizione di controllo scsi, 3/11/0, a VPLEX deve essere analizzato dal rispettivo fornitore dell'array. Questo problema viene attivato dall'array che non è in grado di soddisfare la richiesta di I/O di lettura a causa di un problema di "lettura non ripristinata" sull'array di storage.

Il supporto VNX deve essere coinvolto.

È possibile eseguire il seguente comando CLI sul server di gestione VPLEX per ottenere un elenco delle prime 50 unità logiche interessate dalle condizioni di controllo 3/11/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


Esempio:

Si tratta di un problema a livello di blocchi sull'array di storage e può essere risolto solo intervenendo sull'array di storage stesso.

Non si tratta di un problema di VPLEX, ma di VPLEX che segnala un sintomo rilevato dall'array back-end.

L'uso di "storage-volume resurrect --force" non è valido in questo caso.
Questo comando forza il volume di storage inattivo a essere visualizzato come "vivo" in VPLEX, indipendentemente dallo stato di I/O corrente o dai problemi sull'array di storage sottostante.
Questo comando forza il volume di storage a tornare online fino a quando l'I/O successivo non riesce sull'array di storage sottostante.
Quando l'host richiede lo stesso blocco di dati con il problema 3/11/0 sull'array di storage sottostante, il volume di storage verrà contrassegnato nuovamente come inattivo.
Si tratta di un comportamento previsto e non di un'indicazione di un problema VPLEX.


La presentazione del volume di storage problematico direttamente dall'array di storage all host (ignorando VPLEX) potrebbe consentire all host di utilizzare alcuni dati. Tuttavia, questa azione presenta direttamente all'host un possibile danneggiamento dei dati. L'host continua ad avere problemi di lettura dai blocchi specifici con il problema della condizione di controllo 3/11/0.