VPLEX: Disken är markerad med att maskinvaran är död på grund av SCSI-kontrollvillkoret 3/11/0 från lagringsdisksystemet

Den här händelsen utlöses när VPLEX utför en läsbegäran till det underliggande LUN-minnet för lagringsdisksystemet och disksystemet inte kan hantera I/O på det LUN-blocket, vilket utlöser kontrollvillkoret 3/11/0 (felaktigt block på disksystemet)

Detta är vanligt förekommande i situationer under perioder med tung läs-I/O, som:

• VPLEX-omfattning/enhetsmigrering
• Säkerhetskopieringsåtgärder
• Databasintegritetskontroller

VPLEX-lagringsvolymen är markerad som "hårdvarudöd", men visas som felfri i lagringsdisksystemets gränssnitt.

Exempel på utdata från CLI-kommandot ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

VPLEX-enhet/-omfattningsmigrering (mobilitetsjobb) fastnar vid en viss procent.

Exempel på utdata från CLI-kommandot ll data-migrations/device-migrations/<device_migration_name>
 

Värden ser att VPLEX-lagringen går offline eller markeras som död, och VPLEX-lagringsvolymen markeras också som kritiskt fel eller maskinvarudöd.

Exempeldata som anges i loggen för fast programvara,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

Loggar för fast VPLEX-programvara visar strömmande eller intermittent SCSI/27 (kontrollera villkor) med SCSI Sense-kodposter för 3/11/0, vilket översätts till "Medium Error - unrecovered read error"

Provutdata som anges i loggen för den fasta programvaran under incidenten,

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

För att bekräfta det här problemet kommer följande alltid att vara sant:
key   = 0x3
asc   =  0x11
ascq = 0x0

När VPLEX skickar en I/O-läsförfrågan (0x28) till lagringsdisksystemet kan disksystemet inte hantera I/O-begäran och svarar med kontrollvillkor 3/11/0 för "ej återställt läsningsfel".

VPLEX försöker läsa från ett felaktigt block på lagringsdisksystemet, och eftersom lagringsdisksystemet inte kan hantera denna I/O markerar VPLEX lagringen som död.

Detta är inte matris- eller matriskodspecifikt.

Orsaken till detta är extern för VPLEX och är ett problem på lagringsdisksystemet med LUN.

Det lagringsdisksystem som skickar scsi-kontrollvillkoret 3/11/0 till VPLEX måste undersökas av respektive disksystemleverantör. Problemet utlöses av att disksystemet inte kan hantera läs-I/O-begäran på grund av ett problem med "ej återställd läsning" på lagringsdisksystemet.

VNX-supporten måste vara engagerad.

Följande CLI-kommando kan köras på VPLEX-hanteringsservern för att få en lista över de 50 främsta logiska enheterna som påverkas av kontrollvillkoren 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


Exempel:

Det här är ett problem med blocklagret i lagringsdisksystemet och kan bara lösas genom att vidta åtgärder på själva lagringsdisksystemet.

Detta är inte ett VPLEX-problem, utan VPLEX som rapporterar ett symptom som observerats från backend-disksystemet.

Användningen av "storage-volume resurrect --force" är inte giltig här.
Detta kommando tvingar den döda lagringsvolymen att visas som "levande" i VPLEX oavsett dess aktuella IO-status eller problem på det underliggande lagringsdisksystemet.
Det här kommandot tvingar lagringsvolymen att vara online igen tills nästa I/O misslyckas med det underliggande lagringsdisksystemet.
När värden begär samma datablock som har problemet 3/11/0 på det underliggande lagringsdisksystemet markeras lagringsvolymen som död igen.
Det här är ett förväntat beteende och inte en indikation på ett VPLEX-problem.


Om den problematiska lagringsvolymen presenteras direkt från lagringsdisksystemet till värden (förbigår VPLEX) kan det hända att värden använder vissa data. Den här åtgärden visar dock direkt möjliga skadade data för värden. Värden fortsätter att ha problem med att läsa från de specifika blocken med problemet med 3/11/0-kontrollvillkoret.