VPLEX: Disk merket maskinvare død på grunn av SCSI-kontrolltilstand 3/11/0 fra lagringsarray

Denne hendelsen utløses når VPLEX utfører en leseforespørsel til den underliggende LUN-en for lagringsarrayet, og arrayet ikke kan utføre service på I/O på denne blokken i LUN-en, noe som utløser kontrolltilstanden 3/11/0 (ugyldig blokk på matrisen)

Dette oppstår ofte i situasjoner med tunge lese-I/O-er, for eksempel:

• VPLEX-omfang/enhetsmigrering
• Sikkerhetskopiering
• Integritetskontroller for database

VPLEX-lagringsvolumet er merket "hardware-dead", men vises som sunt på lagringsarraygrensesnittet.

Sampling av utdata fra cli-kommandoen ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

VPLEX-enhet/omfangsmigrering (mobilitetsjobb) blir sittende fast på en viss prosent.

Sampling av utdata fra cli-kommandoen ll data-migrations/device-migrations/<device_migration_name>
 

Verten ser at VPLEX-lagring kobles fra eller er merket som død, og VPLEX-lagringsvolumet er også merket som kritisk feil eller maskinvaredødt.

Eksempeldata som angitt i fastvareloggen,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

VPLEX-fastvarelogger viser strømming eller periodisk SCSI/27 (kontrolltilstand) med SCSI-sensorkodeoppføringer for 3/11/0, som kan oversettes til "Medium Error - unrecovered read error"

Prøveutdata som angitt i fastvareloggen under hendelsen,

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

For å bekrefte dette problemet vil følgende alltid være sant:
key   = 0x3
asc   =  0x11
ascq = 0x0

Når VPLEX sender en I/O-leseforespørsel (0x28) til lagringsarrayet, klarer ikke arrayet å utføre service på I/O-forespørselen, og svarer med kontrollbetingelsen 3/11/0 for "ugjenopprettet lesefeil".

VPLEX forsøker å lese fra en dårlig blokk på lagringsarrayet, og siden lagringsarrayet ikke kan betjene, markerer I/O VPLEX lagringen som død.

Dette er ikke matrise- eller matrisekodespesifikt.

Årsaken til dette er ekstern til VPLEX og er et problem på lagringsarrayet med LUN.

Lagringsarrayet som sender SCSI-kontrolltilstanden, 3/11/0, til VPLEX, må undersøkes av den respektive arrayleverandøren. Dette problemet utløses av at arrayet ikke kan utføre service på I/O-forespørselen på grunn av et problem med ugjenopprettet lesing på lagringsarrayet.

VNX-støtte må være aktivert.

Følgende cli-kommando kan kjøres på VPLEX Management-Server for å få en liste over de 50 beste logiske enhetene som påvirkes av 3/11/0-kontrollforholdene:

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


Eksempel:

Dette er et blokklagsproblem på lagringsarrayet og kan bare løses ved å iverksette tiltak på selve lagringsarrayet.

Dette er ikke et VPLEX-problem, men VPLEX rapporterer et symptom sett fra backend-arrayet.

Bruken av "storage-volume resurrect --force" er ikke gyldig her.
Denne kommandoen tvinger det døde lagringsvolumet til å vises som "levende" i VPLEX, uavhengig av gjeldende IO-status eller problemer på den underliggende lagringsmatrisen.
Denne kommandoen tvinger lagringsvolumet til å koble til igjen til neste I/O ikke klarer den underliggende lagringsarrayen.
Når verten ber om den samme datablokken som har 3/11/0-problemet på den underliggende lagringsmatrisen, vil lagringsvolumet bli merket dødt igjen.
Dette er forventet atferd og ikke en indikasjon på et VPLEX-problem.


Presentasjon av det problematiske lagringsvolumet direkte fra lagringsarrayet til verten (omgåelse av VPLEX) kan la verten bruke noen av dataene. Denne handlingen presenterer imidlertid direkte mulig datakorrupsjon for verten. Verten har fortsatt problemer med å lese fra de spesifikke blokkene med problemet med 3/11/0-kontrollbetingelsen.