VPLEX: Schijf gemarkeerde hardware dood als gevolg van SCSI-controleconditie 3/11/0 van storage-array

Deze gebeurtenis wordt geactiveerd wanneer VPLEX een leesaanvraag uitvoert voor de onderliggende LUN-storage-array en de array geen I/O kan onderhouden op dat blok van de LUN, waardoor de controlevoorwaarde 3/11/0 wordt geactiveerd (slecht blok op de array)Dit wordt vaak gezien in situaties met zware lees-I/O,

zoals:

• Migratie VPLEX-omvang/apparaat
• Back-upbewerkingen
• Integriteitscontroles van databases

Het VPLEX storagevolume is gemarkeerd als "hardware-dead", maar wordt in orde weergegeven op de storage-arrayinterface.

Voorbeelduitvoer van CLI-opdracht ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

VPLEX-apparaat-/omvangmigratie (mobiliteitstaak) loopt vast bij een bepaald percentage.

Voorbeelduitvoer van CLI-opdracht ll data-migrations/device-migrations/<device_migration_name>
 

Op de host wordt VPLEX-storage offline gehaald of als dood gemarkeerd, en het VPLEX-storagevolume wordt ook gemarkeerd als kritieke fout of hardware-dood.

Voorbeelddata zoals genoteerd in het firmwarelogboek,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

VPLEX firmwarelogboeken tonen streaming of intermitterende SCSI/27 (Check Condition) met SCSI Sense Code-vermeldingen voor 3/11/0, wat zich vertaalt naar "Medium Error - unrecovered read error"

Voorbeelduitvoer zoals genoteerd in het firmwarelogboek tijdens het 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

Om dit probleem te bevestigen, zal het volgende altijd waar zijn:
key   = 0x3
asc   =  0x11
ascq = 0x0

Wanneer VPLEX een I/O-leesaanvraag (0x28) naar de storage-array verzendt, kan de array de I/O-aanvraag niet uitvoeren en reageert met controlevoorwaarde 3/11/0 voor "unrecovered read error".

VPLEX probeert te lezen van een slecht blok op de storage-array, en aangezien de storage-array niet in staat is om deze I/O te onderhouden, markeert VPLEX de storage als dood.

Dit is niet specifiek voor array- of arraycodes.

De oorzaak hiervoor ligt buiten VPLEX en is een probleem op de storage-array met LUN.

De storage-array die de scsi-controlevoorwaarde, 3/11/0, naar VPLEX verzendt, moet worden onderzocht door de respectieve arrayleverancier. Dit probleem wordt veroorzaakt doordat de array niet in staat is om de Read I/O-aanvraag te verwerken vanwege een probleem met "unrecovered read" op de storage-array.

VNX Support moet zijn ingeschakeld.

De volgende CLI-opdracht kan worden uitgevoerd op de VPLEX beheerserver om een lijst te krijgen van de top 50 logische eenheden die worden beïnvloed door de controlevoorwaarden 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


Voorbeeld:

Dit is een probleem met de bloklaag op de storage-array en kan alleen worden opgelost door actie te ondernemen op de storage-array zelf.

Dit is geen VPLEX-probleem, maar de VPLEX meldt een symptoom dat wordt gezien door de back-endarray.

Het gebruik van "storage-volume resurrect --force" is hier niet geldig.
Deze opdracht dwingt het dode storagevolume om als "levend" te worden weergegeven in VPLEX, ongeacht de huidige IO-status of problemen met de onderliggende storage-array.
Deze opdracht dwingt het storagevolume om weer online te komen totdat de volgende IO uitvalt naar de onderliggende storage-array.
Wanneer de host hetzelfde datablok met het probleem 3/11/0 op de onderliggende storage-array opvraagt, wordt het storagevolume weer als dood gemarkeerd.
Dit is verwacht gedrag en geen indicatie van een VPLEX-probleem.


Door het problematische storagevolume rechtstreeks van de storage-array naar de host te presenteren (waarbij VPLEX wordt omzeild), kan de host een deel van de data gebruiken. Met deze actie wordt echter direct mogelijke databeschadiging aan de host gepresenteerd. De host blijft problemen ondervinden bij het lezen van de specifieke blokken met het probleem met de controleconditie van 3/11/0.