VPLEX: Storage-Volume im kritischen Fehlerstatus aufgrund der SCSI-Prüfbedingung B/44/00 vom Speicherarray

Das VPLEX-Speicher-Volume befindet sich in einem kritischen Fehlerstatus und das zugrunde liegende Volume funktioniert auf der Arrayseite ordnungsgemäß.

Beispielausgabe des CLI-Befehls: ll /clusters/cluster-1/storage-elements/storage-volumes/<storage-volume name>

VPlexcli:/> ll /clusters/cluster-1/storage-elements/storage-volumes/Symm1234_0000

/clusters/cluster-1/storage-elements/storage-volumes/Symm1234_0000:
Name                           Value
-----------------------------  ------------------------------------------------
application-consistent         false
block-count                    65798400
block-size                     4K
capacity                       251G
description                    -
free-chunks                    []
health-indications             [hardware dead]
health-state                   critical-failure <<--
io-status                      dead
itls                           0x50001442607de710/0x5000097378028844/80,
                               0x50001442607de710/0x50000973780288c4/80,
                               0x50001442607de711/0x5000097378028844/80,
                               0x50001442607de711/0x50000973780288c4/80,
                               0x50001442707de710/0x5000097378028844/80,
                               0x50001442707de710/0x50000973780288c4/80,
                               0x50001442707de711/0x5000097378028844/80,
                               0x50001442707de711/0x50000973780288c4/80,
                               0x50001442a0100410/0x5000097378028844/80,
                               0x50001442a0100410/0x50000973780288c4/80, ...
                               (16 total)
largest-free-chunk             0B
locality                       -
operational-status             error
provision-type                 legacy
storage-array-name             EMC-SYMMETRIX-XXXXXXXXX
storage-volumetype             normal
system-id                      VPD83T3:60000097000000000000000000000000
thin-capable                   false
thin-rebuild                   true
total-free-space               0B
underlying-storage-block-size  512
use                            unusable
used-by                        [extent_Symm1234_0000_1]
vendor-specific-name           EMC

Speicher-Volume im kritischen Fehlerstatus

VPlexcli:/> storage-volume summary
SUMMARY (cluster-1)
StorageVolume Name                        IO Status  Operational Status  Health State
----------------------------------------  ---------  ------------------  ----------------
Symm1234_0000                             dead       error               critical-failure <<--

Ein Beispielauszug aus dem Dial Home, in dem die logische Einheit hervorgehoben wird, die gestorben ist:

                  <EventData><![CDATA[disk VPD83T3:60000970000000000000000000000000: disk died, no mirror exists

Wenn dieses Speicher-Volume nicht Teil eines verteilten Geräts ist, verliert der Host den Zugriff auf dieses virtuelle Volume, was zu einer Nichtverfügbarkeit von Daten führt.

VPlex-Firmwareprotokolle stellen das Streaming von SCSI/27-Ereignissen mit dem SCSI-Sense-Code-Schlüssel 0xb ASC 0x44 ASCQ 0x0 (B/44/00) dar, was übersetzt "INTERNAL TARGET FAILURE" bedeutet.

Beispiel für scsi/27-Instanzen aus firmware.log

128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298782:<6>2016/11/11 06:50:57.94: scsi/27 tgt VPD83T3:60000097000000000000000000000000 cmd 0x2a status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0xb info 0x0 alen 10 csi 0x0 asc 0x44 ascq 0x0 fru 0x0 sks 0x0
128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298783:<6>2016/11/11 06:50:58.00: scsi/27 tgt VPD83T3:60000097000000000000000000000000 cmd 0x2a status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0xb info 0x0 alen 10 csi 0x0 asc 0x44 ascq 0x0 fru 0x0 sks 0x0
128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298784:<6>2016/11/11 06:50:58.16: scsi/27 tgt VPD83T3:60000097000000000000000000000000 cmd 0x2a status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0xb info 0x0 alen 10 csi 0x0 asc 0x44 ascq 0x0 fru 0x0 sks 0x0
128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298785:<6>2016/11/11 06:50:58.30: scsi/27 tgt VPD83T3:60000097000000000000000000000000 cmd 0x2a status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0xb info 0x0 alen 10 csi 0x0 asc 0x44 ascq 0x0 fru 0x0 sks 0x0

21 Wiederholungsversuche werden durchgeführt und das Speicher-Volume wird aufgrund kontinuierlicher Schreibfehler als tot markiert.

128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298797:<4>2016/11/11 06:51:01.42: amf/45 disk VPD83T3:60000097000000000000000000000000: write failure: marking this in-use disk dead
128.221.253.37/cpu0/log:5988:W/"0060166fcbfe192045-1":3298798:<2>2016/11/11 06:51:01.42: amf/97 disk VPD83T3:60000097000000000000000000000000: disk died, no mirror exists

Das Storage-Array gibt B/44/00 für eine Schreib-I/O-Anforderung (0x2a) zurück. Das Array ist nicht in der Lage, die I/O-Anforderung zu bedienen und antwortet mit der Prüfbedingung B/44/00 (INTERNAL TARGET FAILURE)

Wenn das zugrunde liegende Speicher-Volume ein VMAX-Volume ist, können I/O-Fehler aus den unten angegebenen Gründen auftreten:

Der Grund, warum die VMAX die I/O abgebrochen hat, wird nicht an VPlex übergeben. Es gibt viele Gründe für das Auftreten eines internen Zielausfalls und kann durch eine Vielzahl von Ursachen verursacht werden.

Das Storage-Array, das die SCSI-Prüfbedingung B/44/00 an VPLEX sendet, muss vom entsprechenden Arrayanbieter untersucht werden. Dieses Problem wird dadurch ausgelöst, dass das Array die Schreib-I/O-Anforderung aufgrund eines "internen Zielfehlers" auf dem Speicherarray nicht bedienen kann.

Wenn es sich bei dem zugrunde liegenden Array um ein VMAX-Array handelt, kann ein Array aus verschiedenen Gründen die SCSI-Prüfungsbedingung "B/44/00" senden.

Der folgende CLI-Befehl kann auf dem VPLEX Management-Server ausgeführt werden, um eine Liste der logischen Einheiten zu erhalten, die von der B/44/00-Prüfbedingung betroffen sind:

grep "scsi/27" firmware.log* | grep 'key 0xb' |awk '{print $3, $5, $18, $19, $26,$27,$28,$29}'| sort | uniq -c | sort -nr

Beispiel:

service@ManagementServer:~> grep "scsi/27" firmware.log* | grep 'key 0xb' | awk '{print $3, $5, $18, $19, $26,$27,$28,$29}'| sort | uniq -c | sort -nr
 103474 scsi/27 VPD83T3:60000097000000000000000000000000 key 0xb asc 0x44 ascq 0x0
  45254 scsi/27 VPD83T3:60000097000000000000000000000001 key 0xb asc 0x44 ascq 0x0
  32908 scsi/27 VPD83T3:60000097000000000000000000000002 key 0xb asc 0x44 ascq 0x0
  25581 scsi/27 VPD83T3:60000097000000000000000000000003 key 0xb asc 0x44 ascq 0x0
  21043 scsi/27 VPD83T3:60000097000000000000000000000004 key 0xb asc 0x44 ascq 0x0
  10809 scsi/27 VPD83T3:60000097000000000000000000000005 key 0xb asc 0x44 ascq 0x0
  10651 scsi/27 VPD83T3:60000097000000000000000000000006 key 0xb asc 0x44 ascq 0x0

Wenn es sich um ein Array handelt, das nicht von EMC stammt, wenden Sie sich an den entsprechenden Arrayanbieter, um das Problem auf dem Speicherarray zu beheben.

Dies ist kein VPlex-Problem, dies kann entweder ein Back-end-Array- oder ein Fabric-Problem sein.

Das Storage-Array-Team, die Konnektivität oder beide müssen einbezogen werden.