VPLEX: Disco marcado como hardware inativo devido à condição de verificação de SCSI 3/11/0 do storage array

Esse evento é acionado quando o VPLEX executa uma solicitação de leitura para a LUN do storage array subjacente e o array não consegue atender à E/S nesse block da LUN, o que aciona a condição de verificação 3/11/0 (bloco defeituoso no array).

Isso geralmente é visto em situações de tempo de E/S de leitura pesada, como:

• Extensão do VPLEX/migração de dispositivo
• Operações de backup
• Verificações de integridade do banco de dados

O volume de armazenamento do VPLEX é marcado como "hardware-dead", mas mostrado íntegro na interface do storage array.

Exemplo de resultado do comando cli ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

A migração de extensão/dispositivo VPLEX (trabalho de mobilidade) trava em uma determinada porcentagem.

Exemplo de resultado do comando cli ll data-migrations/device-migrations/<device_migration_name>
 

O host vê o armazenamento do VPLEX ficar off-line ou marcado como inativo, e o volume de armazenamento do VPLEX também é marcado como critical-failure ou hardware-dead.

Dados de exemplo conforme anotado no log do firmware,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

Os registros de firmware do VPLEX mostram streaming ou intermitente scsi/27 (condição de verificação) com entradas de código de status SCSI para 3/11/0, que se traduz como "Medium Error - unrecovered read error"

Exemplo de resultado, conforme anotado no log de firmware durante o incidente,

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

Para confirmar esse problema, o seguinte sempre será verdadeiro:
key   = 0x3
asc   =  0x11
ascq = 0x0

Quando o VPLEX envia uma solicitação de leitura de E/S (0x28) para o storage array, o array não consegue atender com sucesso à solicitação de E/S e responde com a condição de verificação 3/11/0 para "unrecovered read error".

O VPLEX tenta ler a partir de um block inválido no storage array e, como o storage array não consegue atender a essa E/S, o VPLEX marca o armazenamento como inativo.

Isso não é específico de array ou código de array.

A causa para isso é externa ao VPLEX e é um problema no storage array com LUN.

O storage array que está enviando a condição de verificação scsi, 3/11/0, para o VPLEX deve ser investigado pelo respectivo fornecedor do array. Esse problema é acionado porque o array não consegue atender à solicitação de E/S de leitura devido a um problema de "leitura não recuperada" no storage array.

O suporte do VNX deve ser acionado.

O seguinte comando da CLI pode ser executado no VPLEX Management-Server para obter uma lista das 50 principais unidades lógicas afetadas pelas condições de verificação de 11/03:

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


Exemplo:

Esse é um problema de camada de bloco no storage array e só pode ser resolvido tomando medidas no próprio storage array.

Esse não é um problema do VPLEX, mas o VPLEX relata um sintoma visto do array de back-end.

O uso de "storage-volume resurrect --force" não é válido aqui.
Esse comando força o volume de armazenamento inativo a aparecer como "ativo" no VPLEX, independentemente de seu status de E/S atual ou de problemas no storage array subjacente.
Esse comando força o volume de armazenamento a ficar on-line novamente até que a próxima E/S falhe no storage array subjacente.
Quando o host solicita o mesmo bloco de dados que tem o problema de 3/11/0 no storage array subjacente, o volume de armazenamento será marcado como inativo novamente.
Esse é o comportamento esperado e não uma indicação de um problema do VPLEX.


Apresentar o volume de armazenamento problemático diretamente do storage array para o host (ignorando o VPLEX) pode permitir que o host use alguns dos dados. No entanto, essa ação está apresentando diretamente uma possível corrupção de dados para o host. O host continua a ter problemas de leitura dos blocks específicos com o problema de condição de verificação 3/11/0.