VPLEX: El disco marcó hardware como inactivo debido a la condición de comprobación de SCSI 3/11/0 desde el arreglo de almacenamiento

Este evento se activa cuando VPLEX realiza una solicitud de lectura al LUN del arreglo de almacenamiento subyacente y el arreglo no puede prestar servicios de I/O en ese bloque del LUN, lo que activa la condición de comprobación 3/11/0 (bloque defectuoso en el arreglo).

Esto se observa comúnmente en situaciones para momentos de gran actividad de I/O de lectura, como:

• Migración de dispositivos/extensiones de VPLEX
• Operaciones de respaldo
• Comprobaciones de integridad de la base de datos

El volumen de almacenamiento de VPLEX está marcado como "hardware inactivo", pero se muestra en buen estado en la interfaz del arreglo de almacenamiento.

Ejemplo de salida del comando de la CLI ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

La migración de dispositivos/extensiones de VPLEX (trabajo de movilidad) se bloquea en un porcentaje determinado.

Ejemplo de salida del comando de la CLI ll data-migrations/device-migrations/<device_migration_name>
 

El host ve que el almacenamiento de VPLEX se desconecta o se marca como inactivo, y el volumen de almacenamiento de VPLEX también se marca como una falla crítica o hardware inactivo.

Datos de muestra como se indica en el registro de firmware,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

Los registros de firmware de VPLEX muestran scsi/27 streaming o intermitente (comprobar condición) con entradas de código de detección de SCSI para el 3/11/0, lo que se traduce como "Medium Error - unrecovered read error"

Ejemplo de salida como se indica en el registro de firmware durante el 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 este problema, siempre se cumplirá lo siguiente:
key   = 0x3
asc   =  0x11
ascq = 0x0

Cuando VPLEX envía una solicitud de lectura de I/O (0x28) al arreglo de almacenamiento, el arreglo no puede atender correctamente la solicitud de I/O y responde con la condición de comprobación 3/11/0 para "error de lectura no recuperado".

VPLEX intenta leer desde un bloque defectuoso en el arreglo de almacenamiento y, dado que este no puede reparar esta I/O, VPLEX marca el almacenamiento como inactivo.

Esto no es específico del arreglo ni del código del arreglo.

La causa de esto es externa a VPLEX y es un problema en el arreglo de almacenamiento con LUN.

El proveedor de arreglos correspondiente debe investigar el arreglo de almacenamiento que envía la condición de comprobación de scsi, 3/11/0, a VPLEX. Este problema se desencadena porque el arreglo no puede atender la solicitud de I/O de lectura debido a un problema de "lectura no recuperada" en el arreglo de almacenamiento.

El soporte de VNX debe estar involucrado.

El siguiente comando de la CLI se puede ejecutar en el servidor de administración de VPLEX para obtener una lista de las 50 unidades lógicas principales afectadas por las condiciones de comprobación del 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


Ejemplo:

Este es un problema de la capa de bloques en el arreglo de almacenamiento y solo se puede resolver si se toman medidas en el arreglo de almacenamiento en sí.

Este no es un problema de VPLEX, sino que VPLEX informa un síntoma visto desde el arreglo de back-end.

El uso de "storage-volume resurrect --force" no es válido en este caso.
Este comando fuerza el volumen de almacenamiento inactivo para que aparezca como "activo" en VPLEX, independientemente de su estado de I/O actual o de los problemas en el arreglo de almacenamiento subyacente.
Este comando fuerza el volumen de almacenamiento a volver a estar en línea hasta que la siguiente operación de I/O falle en el arreglo de almacenamiento subyacente.
Cuando el host solicita el mismo bloque de datos que tiene el problema 3/11/0 en el arreglo de almacenamiento subyacente, el volumen de almacenamiento se marcará como inactivo nuevamente.
Este es el comportamiento esperado y no una indicación de un problema de VPLEX.


La presentación del volumen de almacenamiento problemático directamente desde el arreglo de almacenamiento al host (omitiendo VPLEX) puede permitir que el host utilice algunos de los datos. Sin embargo, esta acción presenta directamente los posibles daños en los datos al host. El host continúa teniendo problemas para leer los bloques específicos con el problema de condición de comprobación 3/11/0.