PowerFlex: El cambio excesivo de funciones de datos causa latencia de I/O y errores

En ciertas transiciones de estado del clúster, la lógica de equilibrio de funciones de MDM puede producir cambios de funciones principal/secundario rápidos y repetidos en muchos combs (estructuras de datos internas que rastrean qué nodos de SDS almacenan cada dato del volumen). Cada switch de función invalida los mapeos de peine del lado del cliente (SDC) y fuerza los reintentos de I/O. Cuando se afectan suficientes peines simultáneamente, la sobrecarga de reintentos acumulativos provoca picos de latencia de I/O y errores de I/O en los hosts de SDC. Según el entorno del host, esto puede provocar tiempos de espera agotados en las I/O de las aplicaciones, que las VM entren en el estado de solo lectura o que el sistema de archivos no esté disponible.

Este comportamiento se ha observado en varios escenarios de activación y no se limita a un solo procedimiento operativo.

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 el sistema de archivos se vuelva 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 a un estado NORMAL sin intervención manual (por lo general)

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

Cuándo puede suceder:

• Este es un escenario poco común. Para que se produzcan eventos de cambio de roles rápidos y repetidos durante una pérdida incorrecta de SDS, deben estar presentes simultáneamente varias condiciones específicas:

• • Entorno a gran escala: cantidad significativa de nodos y volúmenes de SDS
  • Carga de I/O de producción pesada: actividad de I/O significativa en el momento en que falla el SDS
  • La carga de trabajo de reconstrucción supera la capacidad de procesamiento: la cantidad de filas de metadatos que requieren reconstrucción supera el límite por ciclo del balanceador de MDM de 1024 filas

Cada ciclo de rebalanceo puede procesar hasta 1024 filas de metadatos. Cuando se deben reconstruir más filas, el equilibrador no puede terminar el plan actual antes de generar el siguiente.

Lo que sucede:

• El SDS se desacopla abruptamente del MDM (evento SDS_DECOUPLED)
• Todos los SDC que estaban conectados a ese SDS pierden sus conexiones → eventos de desconexión del SDC
• El MDM marca al clúster como DEGRADADO (evento MDM_DATA_DEGRADED).
• Debido a que la cantidad de filas que se reconstruirán es superior a 1024, el equilibrador de MDM no puede completar el plan de reequilibrio actual
• El equilibrador inicia un nuevo plan mientras el plan anterior aún está en ejecución, lo que produce eventos de cambio de roles rápidos y repetidos
• Los SDC de cliente experimentan fallas de I/O continuas (IO_FAULT_NOT_PRI, SCSI sense 0x4). Una vez agotados los reintentos, el SO host notifica errores de I/O, tiempos de espera agotados o un sistema de archivos de solo lectura
• Evidencia de seguimiento de MDM:

Cuando la carga de trabajo de reequilibrio supera el límite de 1024 filas, el seguimiento de MDM muestra el umbral que se está cruzando:

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

Esto indica que 1.098 filas requerían reconstrucción, pero sólo 1.024 podrían procesarse en el ciclo actual. Las filas restantes activan un nuevo plan de reequilibrio antes de que se complete el plan anterior, lo que inicia el ciclo de retroalimentación.

Cadena de eventos:

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS

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

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

Cuándo puede suceder:
Este es un escenario poco frecuente que requiere dos eventos simultáneos:

• Un SDS está ingresando al modo de mantenimiento protegido (PMM)
• El SDS falla o se apaga antes de que se complete la transición al PMM

Lo que sucede: 

• El MDM recibe el comando de entrada del PMM y lo registra como correcto
• El SDS se desacopla inesperadamente mientras la entrada del PMM aún está en curso
• El MDM marca el clúster como DEGRADADO
• El equilibrador de funciones entra en un bucle de cambio de funciones sostenido durante toda la fase de entrada del PMM
• Las filas de datos que no son PMM se intercambian repetidamente en todo el pool de almacenamiento
• La tormenta persiste hasta que el SDS se reincorpora al clúster y completa la transición del modo de mantenimiento

Cadena de eventos:

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

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

Cuando el SDS se reincorpora y se completa el PMM:

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

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

Cuándo puede suceder:
Un SDS ingresa o sale del modo de mantenimiento instantáneo (IMM). Este caso se produce cuando un único SDS está en modo de mantenimiento y el sistema no puede decidir qué SDS debe manejar las I/O para datos específicos.

Lo que sucede:

• El sistema cambia repetidamente qué SDS es responsable de gestionar los mismos datos
• Estos cambios constantes significan que las aplicaciones no saben a dónde enviar sus solicitudes de I/O
• Las I/O se envían al SDS incorrecto, lo que provoca reintentos y demoras
• Las aplicaciones experimentan latencia o tiempos de espera agotados al intentar acceder a los datos afectados

Impacto:

• Impacto en el cliente: Las aplicaciones informan latencia y tiempos de espera agotados mientras el SDS está en IMM
• Duración: Continúa mientras el SDS está en estado IMM
• Recuperación: Automático: se resuelve cuando el SDS sale de IMM

Cadena de eventos:

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

Situación 4: Salida del SDS del modo de mantenimiento protegido (PMM)

Cuándo puede suceder:
Un SDS sale del modo de mantenimiento protegido (PMM). Este escenario se produce durante cada salida del PMM: no es un evento poco frecuente, pero la gravedad depende de cuánto tiempo duró la operación del modo de mantenimiento.

Lo que sucede:

• A medida que el SDS sale del PMM, el equilibrador de funciones debe reasignar los segmentos de datos para incluir el SDS que regresa
• El proceso de rebalanceo afecta a todo el pool de almacenamiento, no solo a los datos del SDS que regresa
• Los cambios de rol se producen en muchos segmentos de datos durante la reintegración
• Las aplicaciones pueden experimentar breves errores de I/O o latencia a medida que se estabilizan las asignaciones de funciones

Impacto:

• Impacto en el cliente: Para ventanas de mantenimiento cortas (menos de 5 segundos), el impacto es apenas perceptible. Para un mantenimiento extendido con I/O activas, se pueden producir miles de cambios de función, lo que provoca paradas de I/O sostenidas
• Duración: Continúa durante la fase de reintegración hasta que se completa el reequilibrio
• Recuperación: Automática

Cadena de eventos:

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

Ejemplo de secuencia de eventos de MDM:

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

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 las operaciones de cambio de roles durante la salida del modo de mantenimiento.

Registros de seguimiento de SDS: En los nodos de SDS, los registros de rastreo muestran operaciones de cambio de funciones repetidas durante la reintegración:

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

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 I/O del SDC de VMware (ESXi) que muestran el comb, 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

Consejo de diagnóstico: Si ve errores de I/O en varios nodos de SDS (no solo en el nodo que tuvo un problema), esto puede indicar una tormenta de switches de funciones en lugar de un comportamiento normal de estado degradado. Si los errores de I/O se aíslan a un solo SDS, este es el comportamiento de estado degradado esperado.

Situación 5: Transiciones de fase del modo de mantenimiento 

Cuándo puede suceder:
Durante la transición, cuando un SDS entra o sale del modo de mantenimiento (IMM o PMM), en el momento en que el estado cambia de normal a MM, o de MM de vuelta a la normalidad.

Lo que sucede:

• El equilibrador de funciones redistribuye las responsabilidades de los datos para adaptarse al cambio
• Se producen breves ráfagas de cambios de funciones a medida que el sistema se adapta a la nueva disposición
• Las aplicaciones pueden experimentar picos de latencia breves durante la transición

Impacto:

• Impacto en el cliente: Breves picos de latencia que duran de segundos a unos minutos. Por lo general, están por debajo de los umbrales de tiempo de espera agotado de la aplicación
• Duración: Dura de segundos a unos minutos y, a continuación, se asienta
• Recuperación: Automática

Cadena de eventos:

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

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 muchos 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.

Este problema se aborda en PowerFlex Core versión 4.5.6. Actualice a esta versión una vez que esté disponible. Comuníquese con el soporte de Dell para obtener información sobre la línea de tiempo de la versión.

Para operaciones de mantenimiento planificadas:

• No realice un ciclo de apagado y encendido ni reinicie un SDS hasta que el MDM registre SDS_MAINTENANCE_MODE_STARTED. Verifique que el SDS haya ingresado completamente al modo de mantenimiento antes de continuar con el mantenimiento físico.
• Monitoree los picos de latencia cuando ingrese o salga del modo de mantenimiento.

Para interrupciones no planificadas del SDS:

• La tormenta es autolimitada y, por lo general, se resuelve en cuestión de minutos a medida que el cúmulo se estabiliza. Si se observa el problema, recolecte getinfo registros de todos los nodos de SDS en el dominio de protección, de todos los MDM de administrador tan pronto como sea posible después del evento y comuníquese con el soporte de Dell.

En raras ocasiones en los que el problema no se resuelve por sí solo, deshabilitar y volver a habilitar temporalmente la reconstrucción puede permitir que el MDM se estabilice:

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# Espere de 5 a 10 segundos y, a continuación, habilite la reconstrucción: 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild