VPLEX: Diskmærkning, der er død på grund af SCSI-kontrolbetingelse 3/11/0 fra storage-array

Denne hændelse udløses, når VPLEX udfører en læseanmodning til det underliggende storagesystems LUN, og systemet ikke kan servicere I/O på den pågældende blok af LUN'en, hvilket udløser 3/11/0-kontrolbetingelsen (dårlig blok på systemet)

Dette ses ofte i situationer med kraftig læse-I/O, f.eks.:

• VPLEX-omfang/enhedsmigrering
• Sikkerhedskopiering
• Integritetskontrol af databaser

VPLEX storage-volume er markeret som "hardware-dead", men vises sundt på storage-array-grænsefladen.

Eksempel på output fra cli-kommando ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

VPLEX enheds-/omfangsmigrering (mobilitetsjob) sidder fast på en vis procent.

Eksempel på output fra cli-kommando ll data-migrations/device-migrations/<device_migration_name>
 

Værten ser, at VPLEX-lageret går offline eller markeres som dødt, og VPLEX-lagerenheden markeres også som kritisk eller hardwaredød.

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

VPLEX-firmwarelogfiler viser streaming eller periodisk scsi/27 (Check Condition) med SCSI Sense Code-poster for 3/11/0, som kan oversættes til "Medium Error - unrecovered read error"

Prøveoutput som noteret i firmwarelog under hændelse,

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 at bekræfte dette problem vil følgende altid være sandt:
key   = 0x3
asc   =  0x11
ascq = 0x0

Når VPLEX sender en I/O-læseanmodning (0x28) til storagesystemet, kan systemet ikke servicere I/O-anmodningen og svarer med kontrolbetingelse 3/11/0 for "ikke-gendannet læsefejl".

VPLEX forsøger at læse fra en dårlig blok på storage-arrayet, og da storage-arrayet ikke er i stand til at servicere dette, markerer I/O VPLEX storage som død.

Dette er ikke system- eller array-kodespecifikt.

Årsagen til dette er ekstern i forhold til VPLEX og er et problem på storage-systemet med LUN.

Det storagesystem, der sender scsi-kontrolbetingelsen 3/11/0 til VPLEX, skal undersøges af den respektive systemleverandør. Dette problem udløses af, at systemet ikke kan servicere læse-I/O-anmodningen på grund af et problem med "ikke-gendannet læsning" på storage-arrayet.

VNX-support skal være aktiveret.

Følgende cli-kommando kan køres på VPLEX-administrationsserveren for at få en liste over de 50 bedste logiske enheder, der påvirkes af 3/11/0-kontrolbetingelserne:

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 bloklagsproblem på storage-arrayet og kan kun løses ved at handle på selve storage-arrayet.

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

Brugen af "storage-volume resurrect --force" er ikke gyldig her.
Denne kommando tvinger den døde storagediskenhed til at blive vist som "levende" i VPLEX uanset dens aktuelle IO-status eller problemer på det underliggende storage-array.
Denne kommando tvinger storagediskenheden til at være online igen, indtil den næste IO ikke når det underliggende storage-array.
Når værten anmoder om den samme datablok, der har 3/11/0-problemet på det underliggende lagersystem, markeres lagerdiskenheden som død igen.
Dette er forventelig adfærd og ikke en indikation af et VPLEX-problem.


Hvis den problematiske storagediskenhed præsenteres direkte fra storage-arrayet til værten (omgå VPLEX), kan værten bruge nogle af dataene. Denne handling præsenterer dog direkte mulig datakorruption for værten. Værten har fortsat problemer med at læse fra de specifikke blokke med problemet med 3/11/0-kontrolbetingelsen.