Migración en vivo con almacenamiento compartido: medir la latencia, análisis de causas y optimización

La Live-Migration con Shared-Storage se considera “el camino fácil”: la máquina virtual (VM) mantiene sus discos virtuales en un almacenamiento compartido, mientras que solo se trasladan a otro host el estado de CPU y RAM. En la práctica, sin embargo, falla sorprendentemente a menudo no por la funcionalidad de la virtualización, sino por la latencia, y precisamente en puntos que en el día a día suelen pasarse por alto: tiempos de respuesta del storage, jitter de red, colas que se desbordan, timeouts mal configurados o una ruta multipath que “flota” en segundo plano.

Por eso esta guía se centra en la realidad operativa: cómo medir de forma fiable la latencia en una Live-Migration con Shared-Storage, acotar sistemáticamente las causas y, a continuación, ajustar para que las migraciones funcionen de forma reproducible —incluye requisitos previos, errores típicos, pasos de comprobación y una estrategia de retroceso clara.

Qué sucede realmente durante una migración en vivo con almacenamiento compartido (y dónde actúa la latencia)

Incluso con Shared-Storage, durante una Live-Migration se mueve más que “solo un poco de RAM”. Lo habitual es un proceso iterativo: se copian por adelantado páginas de memoria (pre-copy) mientras la VM sigue ejecutándose. Dependiendo de la plataforma, al final se transfieren las “dirty pages” (páginas reescritas). Durante un breve momento la VM se detiene (Stun/Pause), se transmite el estado RESTante y la VM se continúa en el host de destino.

El Shared-Storage reduce la cantidad de datos de bloque a copiar, pero aumenta los requisitos de latencia de storage consistente y baja. A partir del momento en que la VM se ejecuta en el host de destino, sus solicitudes I/O (lectura/escritura) deben pasar por nuevas HBAs/NICs del host, nuevas estructuras de colas y, si procede, por rutas distintas hacia el storage. Cualquier imprecisión en la selección de rutas, MPIO/Multipath, propiedad de LUN (LUN-Ownership), opciones de montaje NFS o en el buffering de switches se manifiesta entonces como picos de latencia. Precisamente esos picos aumentan los tiempos de stun, prolongan la duración de la migración o provocan timeouts.

Leer los síntomas correctamente: latencia no es igual a latencia

En el troubleshooting es decisivo qué tipo de “lentitud” observa. Tres patrones son especialmente frecuentes:

• Latencia constante elevada: p. ej. 8–15 ms en lugar de 1–3 ms. Causa frecuente: sobrecarga, profundidad de cola (queue depth) incorrecta, tier de storage equivocado, enlaces demasiado lentos.
• Picos: p. ej. cada 30–120 segundos 50–200 ms. Causa frecuente: retransmisiones, microbursts, flaps de ruta, trabajos en segundo plano (snapshots, rebuilds), expulsiones de caché (cache-evictions).
• Latencia asimétrica: solo en un host o solo en una ruta. Típico de una mala configuración de Multipath, firmware/drivers distintos, mezcla de VLAN/MTU, parámetros LACP/MLAG incorrectos.

Importante: una Live-Migration es una “prueba de esfuerzo” para varias capas a la vez. Si solo mira el hipervisor, a menudo verá solo el síntoma (la migración tarda, la VM tartamudea), no la causa (la cola se llena, NFS tiene retransmisiones, iSCSI está en recuperación de ruta).

Requisitos y trampas típicas (antes de medir)

Condiciones técnicas mínimas

• Tiempo sincronizado (NTP/Chrony): sin marcas de tiempo consistentes es casi imposible correlacionar eventos entre host, switch y storage.
• Rutas estables al Shared-Storage: la redundancia es buena, pero solo si está bien configurada (Multipath/MPIO, política de failover, ALUA/Asymmetric Logical Unit Access).
• Red de migración separada (cuando sea posible): de lo contrario la migración compite con el tráfico de storage o de clientes.

Trampas operativas

• Funcionamiento mixto de MTU: Los Jumbo Frames (MTU 9000) sólo en segmentos parciales de la ruta provocan fragmentación o pérdidas; ambos efectos se perciben como latencia.
• Bufferbloat en puertos de switch/uplinks: alto rendimiento con latencia en aumento; las migraciones son sensibles al jitter.
• Snapshots/Backups durante la migración: en el lado del storage se generan costes de Copy-on-Write o lecturas adicionales.
• Límites de cola pasados por alto: las colas HBA/NIC, dm-multipath, sesiones iSCSI o slots NFS-RPC pueden comportarse durante migraciones de forma distinta que en el funcionamiento normal.
• Criterios de éxito poco claros: «La migración fue lenta» no es una métrica. Defina valores objetivo (Max-Stun, Max-Duración, Max-Pico-de-Latencia).

Medir latencia: qué métricas necesita realmente

Para un análisis de causas sólido, rara vez bastan un ping y un panel de control del storage. Necesita métricas en tres niveles, idealmente paralelas en la misma ventana temporal:

• Efecto en huésped/VM: tiempo de stun, latencia de la aplicación, timeouts, aumento del tiempo de espera de I/O.
• Hypervisor/Host: latencia de dispositivos de bloque (read/write await), ocupación de colas, CPU-Steal/Ready, retransmisiones de red.
• Storage/Red: errores de puerto, drops, retransmisiones, eventos de path-failover, latencia del array (frontend/backend), tasa de aciertos de caché.

Como regla general: si la latencia de bloque en el host es alta, pero el array informa «verde», suele tratarse de un problema de ruta o de red. Si la latencia del array es alta, el storage en sí está bajo presión (tier, caché, discos del backend, rebuild, snapshotting).

Linux-Host: medir latencia de bloque y comportamiento de colas

En hypervisores Linux (p. ej. hosts KVM) iostat y sar son puntos de partida robustos. Proporcionan «await» (tiempo medio de espera de I/O) y «svctm» según la versión del kernel/herramienta de forma limitada; más importante es la combinación de latencia y carga.

# Paket: sysstat
# 1) I/O-Latenz und Auslastung je Device, 1s Intervall, 60 Samples
iostat -x -d 1 60

# 2) Block-Device-Throughput und Queue in sar (falls aktiviert)
sar -d 1 60

# 3) VM-Statistiken (CPU-Wartezeiten, Runqueue) als Kontext
sar -q 1 60

Interpretación en el contexto de migración:

• await aumenta significativamente durante la migración: el camino de almacenamiento o el array recibe carga adicional.
• %util cerca del 100% en dispositivos individuales: cuello de botella en ese dispositivo/ruta (p. ej., se está prefiriendo un camino de multipath).
• avgqu-sz alta: las solicitudes se acumulan (queueing), a menudo presagio de timeouts.

Multipath/MPIO: visualizar el estado de las rutas y el flapping

Multipathing (Linux dm-multipath o Windows MPIO) agrupa varias rutas físicas hacia el almacenamiento. Protege contra fallos, pero puede degradar la latencia significativamente si las rutas son inestables o la política es inapropiada (p. ej., balanceo de carga inadecuado, prioridades ALUA erróneas).

# Überblick über Multipath-Devices, Policies, Prioritäten und Pfade
multipath -ll

# Kernel-Log nach Storage-Resets, Path-Down/Up, Timeout/Abort prüfen
journalctl -k --since "-2h" | egrep -i "multipath|scsi|iscsi|nvme|path down|path up|abort|reset|timeout"

Si durante la migración ve eventos “Path down/up” o reinicios SCSI frecuentes, no son mensajes «cosméticos». Cada recuperación puede provocar picos de latencia del orden de segundos. Precisamente esos picos son los que desestabilizan las migraciones en vivo.

Red de datos: detectar pérdidas, retransmisiones y jitter

Para el almacenamiento compartido, la red suele ser relevante por dos motivos: una vez para la propia migración (transferencia de memoria) y otra para protocolos de almacenamiento como NFS o iSCSI. Las pérdidas y retransmisiones se comportan como latencia, porque TCP debe reenviar y las aplicaciones esperan.

# Interface-Statistiken: Drops, Errors, Retransmits-Hinweise
ip -s link

# TCP-Statistiken: Retransmits, RTO, Out-of-order
ss -s
netstat -s | egrep -i "retrans|timeout|failed|listen|segments"

# Paketmitschnitt zur Korrelation (nur gezielt, kurzzeitig!)
# Beispiel: iSCSI (3260) oder NFS (2049) an einem Storage-Interface
tcpdump -i ethX -nn -s 128 -w /tmp/storage-trace.pcap '(port 3260 or port 2049)'

Un error frecuente es medir la «latencia» únicamente como tiempo de ping. Ping mide ICMP y a menudo solo con paquetes pequeños. Sin embargo, los protocolos de almacenamiento y las migraciones reaccionan ante el acumulación en colas, pérdidas bajo carga, errores de MTU y microbursts. Por eso los contadores de interfaz y las estadísticas TCP son tan importantes.

Windows/Hyper-V-Umfeld: Basismessung ohne Spezialtools

En entornos Windows puede determinar al menos la tendencia con herramientas integradas: latencia de almacenamiento mediante contadores de rendimiento y errores de red mediante estadísticas del adaptador. (Según el entorno, las configuraciones Hyper-V y SMB-Direct/RDMA proporcionan contadores adicionales.)

# Netzadapter-Statistiken (Errors, Discards)
Get-NetAdapterStatistics | Sort-Object -Property Name | Format-Table -Auto

# Performance Counter für Datenträger-Latenz (Beispiel: alle Instanzen)
Get-Counter -Counter "LogicalDisk(*)Avg. Disk sec/Read","LogicalDisk(*)Avg. Disk sec/Write" -SampleInterval 1 -MaxSamples 30

Como orientación general: milisegundos singulares son normales en muchos entornos SAN/NVMe-oF/FC; decenas de milisegundos bajo carga son una señal de aviso, especialmente si se producen picos.

Análisis de causa raíz: procedimiento en pasos claros

El arte consiste en no ajustar las migraciones “a ciegas”, sino en verificar hipótesis. Ha demostrado su eficacia el siguiente orden:

1. Restablecer la reproducibilidad: migración de una VM de prueba o de una VM no crítica, siempre en el mismo intervalo de tiempo, con carga similar.
2. Separar tráfico de migración y de almacenamiento: si es posible, NICs/VLANs separadas; de lo contrario, al menos medir por interfaz.
3. Localizar latencia en el host: ¿qué Device/Multipath-Device muestra un await/Queue elevado?
4. Buscar eventos de ruta: Path-Flaps, Link-Errors, CRC-Errors, iSCSI-Reconnects, NFS-Retrans.
5. Correlacionar eventos del almacenamiento: Snapshot, Rebuild, Cache-Flush, Controller-Failover, Tiering.
6. Revisar ajustes de migración: Concurrency, Bandbreitenlimit, Stun-Threshold, parámetros de Pre-Copy.

Comprobación: ¿Es la propia VM el factor determinante (Dirty-Page-Rate)?

Algunas VMs son “difíciles de migrar”, aunque el almacenamiento y la red estén en orden: bases de datos con un volumen de escritura muy alto o aplicaciones intensivas en memoria generan una alta Dirty-Page-Rate (las páginas de memoria cambian más rápido de lo que se pueden copiar). Entonces la migración entra en iteraciones sucesivas o acaba con un stun elevado.

Prueba práctica: migre una VM relativamente “tranquila” y una VM “caliente” en la misma ventana temporal. Si solo la VM “caliente” presenta anomalías, la causa se sitúa más en la carga/los parámetros de migración que en la latencia del almacenamiento compartido.

Comprobación: asimetría de ruta y ALUA/Ownership

En SAN con ALUA suele haber rutas “optimizadas” y “no optimizadas”. Si un host usa mayoritariamente rutas no optimizadas tras la migración, la latencia aumenta sin errores aparentes. Puede verlo en dm-multipath (prioridades) o en el front-end del array. La solución rara vez es “más ancho de banda”, sino una detección ALUA correcta, prioridades adecuadas y estados de controladores/firmware consistentes en todos los hosts.

Comprobación: retransmisiones NFS y RPC-Slots

En NFS la latencia suele ser una mezcla de respuesta del servidor, red y cola del cliente. Las retransmisiones aparecen cuando se pierden paquetes o las respuestas llegan tarde. Un escollo frecuente: opciones de montaje demasiado agresivas que provocan timeouts bajo carga, o ajustes demasiado conservadores que alargan la recuperación. Aquí se requiere sensibilidad técnica, porque de lo contrario el “tuning” solo desplazará los síntomas.

# NFS-Client-Statistiken (Linux)
nfsstat -c

# Mount-Optionen und NFS-Version prüfen
mount | egrep -i " nfs "
cat /proc/mounts | egrep -i " nfs "

Enfoques de tuning que realmente ayudan en la práctica

Las siguientes medidas están formuladas deliberadamente para que pueda justificarlas y probarlas en procesos de cambio. No todas las medidas encajan en cada entorno; lo importante es que cada una aborde un síntoma concreto.

1) Desacoplar y limitar migraciones (Concurrency y ancho de banda)

Un clásico: varias migraciones en vivo simultáneas generan picos de tráfico que saturan momentáneamente las colas del switch y los frontales de almacenamiento. Eso se manifiesta como una „latencia repentina“. La medida a menudo más eficaz es organizativa/técnicamente simple: menos migraciones paralelas y límite de ancho de banda para el tráfico de migración, para que el tráfico de almacenamiento no se ahogue.

Por qué funciona: reduce los microbursts y estabiliza la latencia de las colas. En muchas infraestructuras una migración algo más larga pero uniforme es claramente mejor que una migración corta con picos duros y Stun.

2) Endurecer los fundamentos de red: MTU, LACP, ECN, búferes

Si utiliza Jumbo Frames: compruebe la MTU de extremo a extremo (NIC del host, vSwitch/bridge, puertos del switch, uplinks, puertos de almacenamiento). Un único tramo a 1500 en un camino de 9000 provoca fragmentación o pérdidas. Para los protocolos de almacenamiento eso es perjudicial.

# MTU am Host prüfen
ip link show | egrep -i "mtu|state"

# Pfad-MTU testen (Beispiel 8972 Payload für MTU 9000; anpassen je nach Overhead)
ping -M do -s 8972 -c 5 <ziel-ip>

Si los retransmisiones/desorden son elevados, examine además el hashing de LACP/MLAG y las rutas asimétricas. Un bonding „funcional“ puede aun así oscilar mucho si el hashing y los patrones de tráfico encajan mal.

3) Estabilizar multipathing: políticas, tiempos de espera, estado de ruta

El objetivo no es un „failover“ lo más agresivo posible, sino un comportamiento predecible. Tiempos de espera demasiado cortos pueden desencadenar cambios de ruta innecesarios ante picos breves; tiempos de espera demasiado largos hacen que las fallas reales sean dolorosas. Compruebe además si alguna ruta es permanentemente peor (errores CRC, nivel de luz en FC, transceptores defectuosos, cables defectuosos) y estropea el balanceo de carga.

Regla práctica: antes de tocar parámetros, estabilice la física (cables/ópticas/puertos) y sólo después las políticas de software.

4) Terminar las cargas paralelas del lado del almacenamiento: snapshots, rebuilds, tiering

Las migraciones en vivo suelen coincidir con ventanas de mantenimiento, y es precisamente entonces cuando también se ejecutan tareas de almacenamiento: rebuilds, scrubs, consolidación de snapshots, movimientos de tiering. Técnicamente es legítimo, pero desde el punto de vista operativo es peligroso si todos los picos coinciden. Planifique las ventanas de migración de modo que los trabajos de fondo del array estén o bien terminados o bien limitados. Si el array soporta QoS (Quality of Service) o priorización, úsela para los datastores críticos.

5) Preparación en la VM: suavizar I/O, mitigar escrituras grandes

Si máquinas concretas „rompen“ las migraciones con su carga, a veces ayudan medidas sencillas: pausar jobs por lotes durante la migración, desplazar temporalmente checkpoints de base de datos, revisar intervalos de flush de logs. No se trata de „forzar“ las aplicaciones, sino de reducir durante la fase crítica la tasa de páginas sucias (Dirty-Page-Rate) y los picos de E/S.

Runbook práctico: medición, migración de prueba, correlación

El siguiente procedimiento está deliberadamente formulado como una lista de comprobación repetible. El objetivo es una pista de auditoría: así podrá demostrar más tarde por qué un cambio ayudó (o no).

1) Antes de la prueba: documentar el estado

• Hosts: versión del kernel/hypervisor, versiones de controladores (NIC/HBA), política de multipath
• Red: MTU, VLANs, LACP/MLAG, red de migración dedicada sí/no
• Almacenamiento: protocolo (NFS/iSCSI/FC), datastore/LUN, trabajos en segundo plano actuales

2) Abrir ventana de medición (Host + Red)

# Terminal A: I/O Metriken
iostat -x -d 1 300

# Terminal B: Kernel-Events (Storage/Netz)
journalctl -k -f

# Terminal C: TCP/Interface-Zähler (alle 10s)
while true; do date; ip -s link; ss -s; sleep 10; done

3) Testmigration durchführen und Zeitpunkt notieren

Anote inicio/fin, nombre de la VM, host origen/destino, datastore/LUN y las migraciones paralelas en curso. Estos metadatos sencillos ahorran horas más adelante.

4) Nach dem Test: Drei Fragen beantworten

• ¿Se hizo visible la latencia en el dispositivo de bloque? (await/cola aumenta)
• ¿Hubo indicadores de red? (drops, retransmits, paquetes fuera de orden)
• ¿Hubo eventos de ruta/reinicio? (logs de multipath/scsi/iscsi)

Sólo cuando pueda responder con claridad a estos tres puntos, el tuning es dirigido. Todo lo demás es «trial and error».

Riesgos y efectos secundarios del Tuning

Muchos cambios de rendimiento conllevan compensaciones. Tres riesgos típicos:

• Timeouts demasiado agresivos pueden provocar failovers innecesarios ante picos breves (más inestabilidad en lugar de menos).
• Límites de ancho de banda excesivos estabilizan la latencia pero alargan tanto las migraciones que se rompen las ventanas de mantenimiento.
• QoS mal aplicada puede dejar otras cargas de trabajo sin recursos o trasladar la latencia en lugar de resolverla (p. ej. de VM-A a VM-B).

Por eso: realizar cambios siempre de uno en uno, medibles y con un plan de reversión.

Estrategia de retroceso: si la Live-Migration no se estabiliza en la ventana

Una buena estrategia de operaciones acepta que no cada entorno puede migrar en caliente cualquier VM en cualquier momento. Defina de antemano cuándo abortar y cómo proceder de forma segura:

• Criterios de abortado: Stun > X ms, Migration > Y minutos, latencia de almacenamiento > Z ms durante N segundos, reinicios de ruta repetidos.
• Fallback 1: Apagar ordenadamente la VM dentro de la ventana definida, realizar una Cold-Migration y arrancar los servicios de forma controlada.
• Fallback 2: Desplazar la carga de trabajo (p. ej., suspender batches), y volver a migrar más tarde.
• Fallback 3: Ampliar la ventana de mantenimiento o dividir en varias migraciones más pequeñas (menos movimientos paralelos).

Importante: una cancelación no es un fracaso si se ejecuta de forma controlada. Los timeouts incontrolados y las oleadas de recuperación son el verdadero riesgo.

Mejores prácticas para migraciones estables a largo plazo

• Monitorización de picos de latencia: No mirar solo medias; observar percentiles (p95/p99) y máximos.
• Disciplina en los cambios: Versionar y documentar los cambios de red y almacenamiento (firmware, configuración de switches, políticas de ruta).
• Pruebas de migración periódicas: No migrar sólo en emergencias. Pequeñas pruebas planificadas mantienen fiables las rutas, políticas y runbooks.
• Separación de clases de tráfico: Separar en la medida de lo posible tráfico de almacenamiento, migración, gestión y tráfico de clientes VM.
• Conocer las dependencias: Ventanas de backup, snapshotting, rebuilds, trabajos ETL — todo lo que genere picos de latencia debe incluirse en la planificación.

Conclusión: latencia medible primero, luego ajustar

En las migraciones en vivo con almacenamiento compartido, rara vez «el hipervisor» decide por sí solo el éxito o el fracaso. Lo determinante es si las rutas de almacenamiento y de red bajo carga de migración proporcionan una latencia baja y predecible y si su operación detecta y mitiga las causas típicas de picos (colas, retransmisiones, flapping de rutas, trabajos en segundo plano). Si correlaciona métricas de forma consistente a nivel de host, red y almacenamiento, la sensación de «la migración a veces es lenta» se transforma en un diagnóstico claro – y de ahí surge un ajuste que sigue siendo efectivo incluso meses después.

Para este tema también son importantes medir la latencia de almacenamiento y la latencia de Vmotion. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica.