Analizar caídas de E/S tras un failover de almacenamiento con iostat, blktrace y dmsetup

Un failover de almacenamiento debería ser, en el mejor de los casos, un breve instante de conmutación: se pierde una ruta, asume la ruta alternativa y las aplicaciones continúan funcionando. En la práctica, sin embargo, tras el failover suele observarse exactamente lo contrario: caídas de I/O después de un failover de almacenamiento, latencias sensiblemente más altas, trabajos “entrecortados”, timeouts en bases de datos o máquinas virtuales que se sienten lentas. Lo insidioso: la perturbación original ha terminado, pero el rendimiento permanece degradado —a veces durante minutos, a veces hasta el siguiente reinicio.

Este artículo muestra una cadena de análisis probada en producción para Linux-sistemas con block storage (FC, iSCSI, SAS, NVMe-oF) y pilas del Device Mapper (Multipath, LVM, dm-crypt). El foco está en tres herramientas que se complementan bien: iostat para un panorama rápido, blktrace para el trazado a nivel de bloque (es decir, el seguimiento de peticiones I/O individuales en el kernel) y dmsetup para obtener transparencia en el Device Mapper (la capa que, por ejemplo, expone dispositivos Multipath y LVM). Además se abordan causas típicas, trampas, pasos de comprobación, opciones de tuning y una estrategia de retroceso viable en operación.

Caídas de I/O después de un failover de almacenamiento: por qué el failover a menudo “sobrevive” pero el rendimiento no

En un failover casi nunca cambia “solo un cable”. Efectos secundarios típicos que frenan el I/O tras la conmutación:

• Degradación de rutas en lugar de redundancia real: Multipath puede funcionar con un único path activo o quedarse conectado a un controlador subóptimo (problema ALUA). ALUA („Asymmetric Logical Unit Access“) describe que en matrices con controladores duales no todos los caminos tienen la misma calidad.
• Efectos de colas/timeouts: Mientras una ruta está caída, las I/O se acumulan. Tras la conmutación hay que procesar ese atasco. Al mismo tiempo, los timeouts y los reintentos pueden incrementar la latencia de forma significativa.
• Comportamiento del write-cache: Los arrays cambian modos de caché, re-sincronizan espejos o modifican políticas de caché. Un array puede funcionar “de forma segura”, pero con un modo de caché más conservador.
• La capa del Device Mapper está „activa“, pero mal parametrizada: Multipath/DM puede quedarse en una política inapropiada (p. ej. parámetros path_selector, min_io, rr_min_io_rq mal ajustados).
• Consecuencias a nivel de aplicaciones y sistemas de archivos: Journaling, replay de logs, recovery de bases de datos, timeouts en almacenamiento de VMs —todo ello puede generar picos de carga que aparentan falsamente un “almacenamiento lento”.

La regla operativa más importante: “Sistema de nuevo online” tras un failover no equivale a “sistema normal”. Necesita una cadena de medición que separe con claridad: dispositivo/array, rutas/Multipath, kernel block layer, sistema de archivos y carga de trabajo.

Requisitos y marco de seguridad para el análisis

Antes de profundizar con trazas, aclare dos puntos: (1) ¿Tiene permiso para instalar herramientas y lanzar traces del kernel en el host afectado? (2) ¿Está el sistema en un estado en el que diagnósticos adicionales no empeoren la situación? blktrace genera overhead, especialmente con tasas de I/O muy altas. Trabaje, por tanto, de forma breve, focalizada y —si es posible— primero en una ventana de mantenimiento o en un nodo comparable.

Para los pasos siguientes suelen ser necesarios paquetes: sysstat (iostat) y blktrace/btt. En muchas distribuciones estos paquetes están en los repositorios estándar. Compruebe también si su almacenamiento está conectado mediante Multipath (Device Mapper) o p. ej. se usa directamente como /dev/sdX —eso influye en el punto donde debe medir.

Panorama rápido con iostat: ¿qué está realmente roto?

iostat proporciona indicios rápidos de si tiene un problema de latencia, de saturación o un problema de CPU/planificador. Para escenarios de failover es especialmente importante distinguir entre tiempo de servicio, cola y rendimiento. En las salidas de iostat encontrará típicamente:

• r/s, w/s, rkB/s, wkB/s: IOPS y rendimiento
• await: tiempo medio de espera por E/S (incluye cola + servicio)
• svctm (según la versión): tiempo de servicio (no siempre fiable en kernels modernos)
• %util: aproximación de utilización (interpretar con cautela en NVMe/múltiples colas)

Capturar la línea base: sobre todo en los dispositivos correctos

Un tropiezo frecuente: observa /dev/sdX, pero la aplicación usa /dev/mapper/mpathX o un LVM-LV por encima. Por eso mida tanto los dispositivos DM como los dispositivos de bloque subyacentes. Comience con una salida que muestre dispositivos, estadísticas extendidas y intervalos cortos:

# 1-Sekunden-Intervalle, 30 Samples, inklusive Device-Stats
iostat -dxm 1 30

Interpretación para failover:

• await aumenta notablemente, %util permanece moderado: a menudo reintentos/timeouts, problemas de ruta, o encolamiento en una capa anterior (DM, HBA, red).
• %util cerca del 100% y rendimiento bajo: saturación en I/Os pequeños o una ruta que se ha vuelto „estrecha“ (p. ej., solo un controlador activo).
• Solo un único dispositivo muestra valores atípicos: más bien específico de ruta/dispositivo (p. ej., un conjunto de LUN), no genérico.

Patrones típicos de iostat tras un failover

En la práctica, tras un failover de almacenamiento suele verse una combinación de (a) un await claramente mayor y (b) IOPS fluctuantes, pese a que la CPU está tranquila. Esto suele indicar latencias „no deterministas“ debidas a reintentos, cambios de ruta (‚flip-flop‘) o a un array que se está re-sincronizando internamente. Si en el mismo periodo ve mensajes del kernel relacionados con SCSI/iSCSI (véase la sección siguiente), es un fuerte indicio de que la latencia no proviene del sistema de ficheros, sino de la cadena de E/S subyacente.

Asegurar el contexto: logs y estado del kernel en torno al failover

Antes de profundizar con blktrace, asegure el contexto. Especialmente en un failover los sellos temporales son cruciales para correlacionar picos de E/S con eventos de ruta.

# Kernel- und Systemlogs im relevanten Zeitraum (Beispiel: letzte 2 Stunden)
journalctl -k --since "2 hours ago" --no-pager
journalctl --since "2 hours ago" --no-pager | tail -n 300

Preste atención a indicios como: link down, target reset, abort task, timed out, recovered error. En iSCSI suelen aparecer mensajes sobre reconexiones de sesión; en FC más bien resets del HBA o del layer SCSI. Estos mensajes suelen explicar por qué el await aumenta, aunque la LUN „presente“ esté.

Verificar el Device-Mapper con dmsetup: ¿qué hace realmente Multipath?

Si utiliza Multipath, ist dmsetup una herramienta precisa para comprender la vista del Device Mapper. Device Mapper es una capa del kernel que compone dispositivos de bloque virtuales a partir de otros dispositivos de bloque – Multipath, LVM y dm-crypt son usuarios típicos.

Comience con una vista general para ver los nombres y las dependencias:

# Übersicht über DM-Devices und Abhängigkeiten
lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

dmsetup ls --tree

Importante es la pregunta: ¿Qué dispositivo DM es el cuello de botella? Un LV (LVM) puede parecer sano, mientras que Multipath subyacente usa solo una ruta o conmuta continuamente.

dmsetup status y table: Policy, rutas, estados de error

Con status y table verá cómo el kernel opera actualmente el dispositivo:

# Beispiel: Status und Tabelle eines Multipath-Devices
dmsetup status /dev/mapper/mpathX
dmsetup table  /dev/mapper/mpathX

Qué debe buscar aquí:

• path groups: ¿Cuántos grupos de rutas hay y cuál está activa?
• failed/faulty paths: ¿Hay rutas marcadas como defectuosas que aun así hagan ‚flapping‘?
• Policy: round-robin, queue-length, service-time – según el array, una política puede ser más adecuada que otra.

Si además utiliza multipath-tools, multipath -ll suele ofrecer la vista más legible, incluyendo el estado ALUA. No es dmsetup, pero en la práctica es el complemento más rápido:

multipath -ll

Problemas frecuentes en Multipath tras un failover

• Sólo una ruta activa: rendimiento reducido a la mitad o peor, además de mayor latencia en picos.
• ALUA mal interpretado: el host usa rutas ’non-optimized‘ (controlador subóptimo), lo que degrada latencia y rendimiento.
• Encolado al caída de rutas (Path-Down): en algunas configuraciones las E/S se ponen en cola cuando todas las rutas están temporalmente caídas. Esto evita errores, pero al restablecerse puede generar una larga cola de procesamiento.
• Flush/Failback: un failback demasiado agresivo puede provocar que el host cambie continuamente de nuevo mientras el array aún no está estable.

El puente entre síntoma y causa: usar blktrace correctamente

Cuando iostat y dmsetup indican que hay un problema de I/O, blktrace a menudo revela dónde se pierde tiempo. blktrace se engancha a la capa de bloques y registra eventos (Queue, Dispatch, Completion). Con ello puede distinguir: ¿se acumula I/O en el kernel, o está “afuera” (almacenamiento/transporte)?

Importante: realice el trazado en el dispositivo correcto. En Device Mapper puede ser útil trazar tanto el dispositivo DM como el dispositivo físico subyacente. En muchos entornos basta actuar sobre el dispositivo DM multipath, porque allí se hace visible el encolamiento.

Trazado breve y dirigido durante el problema

Comience con un trazado breve (p. ej. 30–60 segundos) para mantener baja la sobrecarga:

# 60 segundos de trazado en un dispositivo (ej.: dispositivo dm o nvme0n1)
# -d: dispositivo, -w: duración, -o: directorio de salida
mkdir -p /var/tmp/blktrace-iofailover
blktrace -d /dev/mapper/mpathX -w 60 -o /var/tmp/blktrace-iofailover/trace

Los datos en bruto son difíciles de leer. Use a continuación btt (Block Trace Times) para analizar tiempos de espera y distribuciones:

# Análisis de los archivos de traza
btt -i /var/tmp/blktrace-iofailover/trace.* -o /var/tmp/blktrace-iofailover/report

Lo que típicamente querrá extraer:

• Queue-to-Dispatch: tiempo que las solicitudes esperan en el kernel antes de enviarse al dispositivo. Valores altos indican encolamiento en el kernel/DM o efectos del planificador.
• Dispatch-to-Complete: tiempo «en el trayecto» hacia el almacenamiento y de vuelta. Valores altos indican latencia de almacenamiento/transporte, problemas de ruta o reintentos.

Cuándo blktrace falla o puede inducir a error

Hay límites: con cargas de I/O extremadamente altas el trazado puede volverse demasiado grande o distorsionar los tiempos. Además, blktrace sólo muestra lo que ocurre en la capa de bloques —no la causa exacta en la red SAN/iSCSI o en el array. Si Dispatch-to-Complete se dispara, deberá continuar con herramientas para HBA/NIC y del array (p. ej. puertos de switch, iSCSI-RTT, FC-Counters, puertos front-end del array).

Secuencia de comprobaciones como runbook: de „síntoma“ a „causa raíz“

En la operación de hosting ayuda una secuencia fija para que no pase nada por alto bajo presión. La siguiente secuencia está diseñada para que comience con una baja profundidad de intervención y sólo después pase a trazados.

Paso 1: delimitar el nivel afectado

• ¿Está afectado solo un host o varios? Varios hosts apuntan al array/transporte, un único host más bien a HBA/NIC/configuración de multipath.
• ¿Está afectado solo un conjunto de LUNs o todas las LUNs? Solo un conjunto puede indicar un problema en un tier/pool o una asignación incorrecta de LUN.
• ¿El problema es principalmente de lectura o de escritura? Las latencias de escritura tras un failover pueden aumentar más debido a cambios en la caché o a reconstrucciones (rebuilds).

Paso 2: iostat a nivel DM y físico

# Parallel-Ansatz: iostat laufen lassen und Zeitpunkt notieren
iostat -dxm 1

Anote los dispositivos llamativos (dm-*, mpath*, sdX, nvme*), los picos de await y el comportamiento de %util. Esto será más tarde el ancla para la correlación de logs y las trazas.

Schritt 3: Pfadstatus und DM-Stack prüfen

dmsetup ls --tree
multipath -ll 2>/dev/null || true
dmsetup status /dev/mapper/mpathX

Si observa aquí que solo un camino está activo o que los caminos aparecen como „faulty“, normalmente ya tiene el punto de partida principal: estabilizar el transporte, comprobar ALUA/Failback, ajustar Path-Checker/Timeouts.

Schritt 4: Kernel-Logs auf Resets/Timeouts

journalctl -k --since "30 min ago" --no-pager | egrep -i "scsi|iscsi|nvme|timeout|reset|abort|multipath|blk_update_request"

Los resets y timeouts suelen explicar directamente los picos de latencia. Es importante saber si los errores continúan ocurriendo (recurrentes) o solo se produjeron durante la ventana de Failover.

Schritt 5: blktrace kurz und gezielt

mkdir -p /var/tmp/blktrace-iofailover
blktrace -d /dev/mapper/mpathX -w 30 -o /var/tmp/blktrace-iofailover/trace
btt -i /var/tmp/blktrace-iofailover/trace.* -o /var/tmp/blktrace-iofailover/report

Si la mayor parte del tiempo está en Dispatch-to-Complete, escale hacia Storage/Red/SAN. Si está en Queue-to-Dispatch, centre la investigación en DM-Queueing, el scheduler, los parámetros de cola y la interacción con la carga de trabajo.

Typische Ursachen nach Failover – und was Sie konkret prüfen

1) ALUA und „falscher Controller“: Optimized vs. Non-Optimized

En arrays con controladores duales, una ruta puede „funktionieren“ pero no ser la preferida. Entonces verá latencia y menor rendimiento sin errores claros. Compruebe con multipath -ll si las rutas están marcadas como active/optimized. Si no: revise la configuración ALUA en el host, la asignación de rutas en el array (Target-Ports) y, si procede, las opciones de failback. Riesgo: un failback demasiado agresivo puede provocar un ping-pong tras el Failover.

2) Timeout- und Retry-Kaskaden im SCSI/iSCSI-Stack

Failover suele significar: ausencia de respuestas durante un breve periodo y luego recuperación. Si los timeouts y reintentos son demasiado largos, cada petición I/O queda „mitgeschleppt“. Se observa como altos valores de await, a menudo en forma de ráfagas. Compruebe los registros del kernel y la estabilidad de las sesiones iSCSI (para iSCSI, además, latencias de red, pérdidas y MTU/Path-MTU). Las contramedidas dependen en gran medida de la pila: los timeouts deben ajustarse a los tiempos de failover del array sin provocar que la aplicación registre errores.

3) Multipath Queueing: Schutz vor Errors, aber teuer in der Nachwirkung

Multipath puede almacenar en cola I/Os con „queue_if_no_path“ o mecanismos similares cuando todas las rutas desaparecen. Esto evita errores de I/O en las aplicaciones, pero al restablecerse puede generar una cola muy larga. iostat muestra entonces durante mucho tiempo valores altos de await, aunque la ruta ya esté disponible. Aquí la decisión operativa es crítica: ¿es aceptable tener errores breves (y reintentos en la aplicación), o es imprescindible el encolamiento porque, de lo contrario, se podrían corromper archivos/VMs? No hay una respuesta universal, pero debe decidirse conscientemente y documentarse.

4) Scheduler- und Queue-Parameter nach Device-Wechsel

Tras un failover el dispositivo visible puede cambiar (p. ej. otra ruta HBA) o los parámetros pueden comportarse de forma distinta. En NVMe y en dispositivos SCSI modernos el I/O-scheduler clásico tiene menor peso, pero los ajustes de cola, nr_requests y los Device-Queue-Limits aún pueden imponer límites. Compruebe si los parámetros de la cola de bloques difieren entre „normal“ y „degradado“. Trampa: las reglas udev o los perfiles de tuning se aplican solo en el arranque, no en el evento de cambio de ruta.

5) Sistema de archivos y aplicación: „Trabajo posterior“ tras una parada de I/O

Si durante el failover no se pudo escribir durante un breve periodo, las aplicaciones recuperan el retraso después: se procesan los journals, se rellenan las cachés y se vacían/flush los logs de la base de datos. Eso puede parecer un “almacenamiento lento”, pero con frecuencia es simplemente un pico de carga. La diferenciación se consigue con blktrace (cola frente a latencia del dispositivo) y con métricas de la aplicación (p. ej., tiempos de checkpoint de la base de datos). Compruebe también si en el host existe presión de memoria (Memory-Pressure) o CPU-Steal (virtualización): eso puede frenar indirectamente el I/O.

Trampas en la práctica

• Dispositivo incorrecto rastreado: Traza en /dev/sdX, aunque se utilice /dev/mapper/mpathX (o viceversa). Resultado: aparentemente „nada llamativo“.
• Mediciones sin referencia temporal: Sin marcas de tiempo exactas (evento de failover, mensajes de log, intervalos de iostat) se confunden rápidamente causa y efecto.
• Sobreinterpretar picos aislados: Tras un failover son normales picos cortos. Relevante es la degradación persistente o los picos recurrentes.
• Cambios bajo carga: Modificar la política de multipath o los timeouts en medio del incidente puede mejorar o empeorar la situación. Planifique una opción de reversión.

Implementación: estabilizar, luego optimizar

Una vez que haya acotado la causa, priorice en este orden:

1. Restablecer la estabilidad: rutas estables, sin flaps, sin resets/Timeouts recurrentes.
2. Usar las rutas correctas: asignación ALUA/controlador correcta, estrategia de failback adecuada.
3. Decidir el queueing conscientemente: el queueing protege frente a errores, pero puede prolongar el RTO (Recovery Time Objective).
4. Ajuste de rendimiento: solo cuando esté estable, trabajar en Queue-Depth, scheduler y políticas.

Documente las decisiones tomadas en el runbook: ¿Qué parámetros de multipath.conf están configurados? ¿Qué tiempos de failover son realistas por parte del storage? ¿Qué aplicaciones toleran errores de I/O a corto plazo y cuáles no?

Estrategia de reversión: deshacer cambios de forma segura

Especialmente con cambios en multipath y en timeouts necesita una estrategia de reversión clara. En la práctica significa:

• Versionar la configuración: multipath.conf, reglas udev, sysctl/parametros del kernel en Git o en un sistema de gestión de configuración.
• Definir el paso de rollback: ¿Cómo vuelve usted al último estado conocido? ¿Quién puede autorizarlo?
• Planificar ventana de mantenimiento: Algunos cambios requieren reinicio del servicio o solo surten efecto tras un re-scan. Planifíquelo antes de actuar „on the fly“.
• Comprobación posterior: línea base de iostat, estado de rutas, logs en busca de nuevos errores, y una comprobación por muestreo rápida con blktrace si los síntomas eran inequívocos antes.

Buenas prácticas para la operación: para que el próximo failover no sea un incidente de rendimiento

• Probar y medir los failovers: No solo «funciona/no funciona», sino registrar latencia/IOPS antes, durante y después del failover.
• Monitorización a nivel de rutas: no solo que la LUN sea accesible, sino el número de rutas activas, el estado ALUA, reinicios recurrentes.
• Runbook con puntos de medición claros: patrones de iostat, salidas de dmsetup/multipath, ventana de blktrace, filtros de logs.
• Ajustar los timeouts del lado de la aplicación: los timeouts de bases de datos, VM y sistema de archivos deben ajustarse a la realidad del failover de almacenamiento.

Conclusión

Las caídas de I/O tras un failover de almacenamiento rara vez son «simple mala suerte», sino que suelen ser la interacción entre el estado de las rutas, el comportamiento del Device Mapper, los timeouts/reintentos y la carga que se genera tras el conmutado. Con una cadena de diagnóstico consecuente basada en iostat (síntoma y alcance), dmsetup (pila y rutas) y blktrace (dónde se pierde el tiempo) obtiene en poco tiempo conclusiones sólidas, en lugar de conjeturar a ciegas.

Si documenta los resultados como runbook y evalúa las pruebas de failover no solo desde la funcionalidad sino también desde el rendimiento, reduce el riesgo de que un failover exitoso acabe convirtiéndose en un incidente operativo.

Para este tema también son importantes el troubleshooting de failover de almacenamiento y el análisis con iostat. El artículo sitúa estos aspectos de forma comprensible y muestra qué es relevante en el día a día.