Indicadores comunes

• MDM_DATA_DEGRADED evento seguido de una latencia de I/O sostenida que dura de 1 a 15+ minutos
• Los hosts SDC informan errores de I/O o tiempos de espera agotados de I/O durante la ventana degradada
• VMware (ESXi): Tiempos de espera agotados de latidos de VMFS, errores de hardware de SCSI (sense data: 0x4 0x0 0x0), VM que ingresan al estado de solo lectura, posible conmutación por error de HA
• Linux: Errores de I/O en los registros del sistema (/var/log/messages, dmesg), es posible que las aplicaciones experimenten tiempos de espera agotados de I/O o que los sistemas de archivos se vuelvan a montar en modo de solo lectura
• Los registros de eventos de MDM muestran el sistema en estado DEGRADED durante más tiempo de lo esperado para una sola pérdida de SDS
• Finalmente, el sistema se recupera automáticamente al estado NORMAL sin intervención manual (en la mayoría de los casos)

Nota: Al momento de escribir este artículo, este problema solo se ha informado en entornos con hosts de SDC de Linux y VMware (ESXi). No hay informes conocidos de que este comportamiento afecte a los hosts de Windows SDC, aunque el fallo subyacente está en la lógica del núcleo de MDM y no es específico del SO.

Situación 1: Pérdida repentina del SDS (sin modo de mantenimiento)

Un SDS se desacopla inesperadamente. Los SDC se desconectan del SDS afectado, el clúster entra en DEGRADED y la tormenta de equilibrio de funciones comienza de inmediato. Ejemplo de secuencia de eventos de MDM:

SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Los errores de I/O comienzan en cuestión de segundos después del evento de desacoplamiento en varios nodos SDS sobrevivientes, no solo en el SDS que se perdió.

Situación 2: Apagado del SDS durante la entrada del PMM

Un SDS se apaga antes de que termine de ingresar al modo de mantenimiento protegido. El MDM registra la solicitud de PMM seguida de un desacoplamiento inesperado antes de SDS_MAINTENANCE_MODE_STARTED se registra. Ejemplo de secuencia de eventos de MDM:

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

La tormenta de equilibrio de funciones persiste hasta que el SDS se reincorpora y completa la transición del modo de mantenimiento.

 Situación 3: SDS en modo de mantenimiento instantáneo (IMM)

Un SDS ingresa o sale del IMM. Durante la transición, se observan picos de latencia de I/O. El MDM no informa el estado DEGRADED en este escenario, pero los hosts de SDC experimentan reintentos de I/O y latencia hasta que se completa la transición de IMM.

Situación 4: Salida del SDS del modo de mantenimiento

Un SDS sale de IMM o PMM. Durante la reintegración, es posible que se produzcan errores de I/O brevemente a medida que la lógica de equilibrio de funciones reasigne los peines al SDS que regresa.

 Resultados del registro: 

Registros de eventos de MDM: El registro de eventos de MDM muestra la secuencia de nivel de clúster. Los indicadores clave son un desacoplamiento de SDS seguido de un estado DEGRADED, con el sistema permaneciendo en DEGRADED más tiempo de lo esperado para una sola pérdida de SDS:

SDC_DISCONNECTED_FROM_SDS_IP    WARNING  SDC <name> disconnected from the IP address <ip> of SDS <name>
MULTIPLE_SDC_CONNECTIVITY_CHANGES INFO   Multiple SDC connectivity changes occurred
SDS_DECOUPLED                   ERROR    SDS: <name> (ID: <id>) decoupled
MDM_DATA_DEGRADED               ERROR    The system is now in DEGRADED state

Cuando la tormenta se resuelve y el sistema se estabiliza:

MDM_DATA_NORMAL                 INFO     The system is now in NORMAL state

Registros de seguimiento de SDS:

En los nodos de SDS sobrevivientes (no en el SDS que se perdió), los registros de seguimiento mostrarán respuestas repetidas de fallas de I/O para peines que deberían estar estables. Esto indica que la tormenta de equilibrio de roles está invirtiendo activamente las asignaciones primarias/secundarias:

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

Se observaron fallas de IO en los nodos SDS sobrevivientes durante la tormenta:

IO_FAULT_NOT_PRI    -- SDS received IO for a comb it is no longer primary for
IO_FAULT_WRONG_COMB_GEN -- SDC's cached comb generation is stale
IO_HARD_ERROR       -- SDS could not complete the IO (partner SDS unreachable)

Un alto volumen de entradas de funciones de switch en una ventana de tiempo breve (miles o más en cuestión de segundos) es el indicador definitivo del lado del SDS de este problema.

Registros de SDC/host:

Reintentos de IO del SDC de VMware (ESXi) que muestran el peine, el SDS de destino y el código de falla:

vmkernel log

PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

Si se reintenta el escape, se devuelven errores de SCSI:

sense data: 0x4 0x0 0x0    -- SCSI Hardware Error

Tiempos de espera agotados de latido de VMFS en los almacenes de datos afectados:

HBX: 3089: '<datastore>': HB at offset <offset> - Waiting for timed out HB

Hosts de SDC Linux -- /var/log/messages o dmesg. Aparecieron errores de I/O a través de la capa SCSI o el sistema de archivos:

sd <device>: [scini] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
blk_update_request: I/O error, dev <device>, sector <sector>
EXT4-fs error (device <device>): ext4_journal_check_start: Detected aborted journal

Punto clave: La característica distintiva es que aparecen errores de I/O en varios nodos SDS, no solo en el SDS que se perdió. Si los errores de I/O se aíslan al SDS fallido, el problema es el comportamiento de estado degradado esperado, no este defecto.

Impacto

Durante la tormenta de equilibrio de funciones, los picos de latencia de I/O causan paradas temporales de I/O en los volúmenes afectados. La duración y la gravedad del impacto dependen del tamaño del clúster, la carga de I/O y la cantidad de peines afectados.
El impacto observado ha incluido lo siguiente:

• Paradas de E/S que duran aproximadamente 15 segundos a 15+ minutos
• VM que ingresan al estado de solo lectura
• Tiempos de espera agotados de latidos de VMFS en hosts ESXi, lo que puede desencadenar alertas de estado de alimentación de VM o conmutación por error de HA
• Tiempos de espera agotados de I/O de aplicaciones en hosts SDC Linux
• Los entornos a gran escala pueden experimentar un impacto generalizado en cientos o miles de VM

No se observó pérdida de datos en ningún caso informado. El sistema se recupera automáticamente una vez que la tormenta de equilibrio de funciones disminuye y el clúster vuelve al estado NORMAL. La gravedad del impacto escala con el tamaño del dominio de protección. Los entornos con una gran cantidad de nodos, volúmenes e I/O activas de SDS en el momento del evento experimentarán un mayor impacto.

Un fallo de software en la lógica de equilibrio de funciones de MDM provoca un bucle de retroalimentación cuando el clúster cambia de estado debido a una operación de modo de mantenimiento o pérdida de SDS. En ciertas condiciones, el MDM reasigna repetidamente qué nodos de SDS son responsables de prestar I/O a los peines afectados. Cada reasignación invalida la vista almacenada en caché del SDC de dónde se encuentran los datos, lo que fuerza los reintentos de I/O. Cuando una gran cantidad de peines se ven afectados simultáneamente, el volumen de reasignaciones supera la capacidad de actualización de los SDC, lo que genera errores de I/O sostenidos en varios hosts. Por lo general, la tormenta es autolimitada. Se resuelve una vez que el clúster se estabiliza, pero la duración depende del tamaño del dominio de protección y de la carga de I/O en el momento del evento.

Información adicional