Problema

En entornos de producción basados en Azure, es frecuente que una VM albergue tanto la capa de aplicación (frontend/backend) como el acceso administrativo vía SSH. Cuando la VM empieza a experimentar latencia alta en la conexión SSH (segundos para establecer la sesión y retrasos al ejecutar comandos) y, simultáneamente, el sitio web alojado se vuelve inaccesible, el síntoma suele confundirse como un fallo de la aplicación. Sin embargo, el patrón típico es:

  1. SSH sigue respondiendo, pero con retardos perceptibles.
  2. El endpoint HTTP/HTTPS deja de responder (timeout o conexión rechazada).
  3. Los procesos de la aplicación siguen activos en el sistema.
  4. Después de unos minutos, tanto SSH como la web vuelven a la normalidad sin intervención manual.

Este comportamiento intermitente indica un problema de recursos compartidos o de red que afecta a la pila de transporte, más que a la lógica de la aplicación.

Causa

Existen varias causas recurrentes que generan este tipo de síntomas en una Azure VM con Ubuntu:

  1. Contención de recursos de la VM

    • CPU saturada por procesos de recolección de basura, compresión o picos de tráfico. Cuando la CPU está al 100 % la respuesta del kernel a paquetes TCP se retrasa, afectando tanto SSH como HTTP.
    • Memoria insuficiente que lleva a swapping intensivo; el I/O de swap aumenta la latencia de cualquier operación de red.
    • I/O de disco (alta latencia en discos SSD gestionados) que retrasa la escritura de buffers de red.

  2. Problemas de red a nivel de NIC o del plano de Azure

    • Throttling de la NIC cuando la VM supera el ancho de banda asignado (por ejemplo, burst de tráfico HTTP).
    • Pérdida de paquetes en la ruta entre el cliente y la IP pública, a menudo causado por congestión en el Azure Load Balancer o en la ruta de salida del VNet.
    • Reasignación de la dirección IP pública (aunque sea estática) tras eventos de mantenimiento de Azure, lo que provoca breves interrupciones de conectividad.

  3. Configuración de red en Ubuntu

    • Filtros de iptables/nftables que inspeccionan cada paquete y generan carga adicional bajo alta concurrencia.
    • TCP tuning inadecuado (por ejemplo, valores por defecto de net.core.somaxconn o net.ipv4.tcp_tw_reuse) que no escalan bajo picos de conexiones.

  4. Mantenimiento interno de Azure

    • Eventos de Live Migration o Hardware Maintenance pueden pausar momentáneamente la VM, generando latencia sin reiniciar los procesos.

En la práctica, la mayoría de los incidentes combinados de SSH lento y sitio caído se deben a contención de CPU + I/O o a pérdida de paquetes en la capa de red. La clave está en capturar métricas en tiempo real para diferenciar ambas situaciones.

Solución

Una estrategia de diagnóstico y mitigación se divide en tres fases: monitorizar, aislar y remediar.

1. Monitorizar en tiempo real

Implementa una colección de métricas que cubra CPU, memoria, disco, red y latencia de TCP. Herramientas recomendadas:

  • Azure Monitor → crea alertas en Percentage CPU > 80% y Network In/Out > 80% del límite de la NIC.
  • collectd o Telegraf dentro de la VM → envía datos a un endpoint de Grafana/InfluxDB.
  • netstat / ss para contar sockets en estado TIME_WAIT o CLOSE_WAIT.
  • ping y traceroute desde una máquina externa para detectar pérdida de paquetes.

2. Aislar la causa

Ejecuta los siguientes comandos cuando el síntoma aparezca. Observa si los valores indican contención de recursos o problemas de red.

# CPU y carga del sistema
top -b -n1 | head -15

# Uso de memoria y swap
free -m

# I/O de disco
iostat -xz 1 5

# Estadísticas de red a nivel de NIC
sar -n DEV 1 5

# Conteo de sockets y estado TCP
ss -s

# Latencia de ping a la IP pública de la VM (desde otro host)
ping -c 10 <IP_PUBLICA>

# Traceroute para ver saltos y pérdida
traceroute <IP_PUBLICA>
  • Si top muestra CPU > 90 % y iowait elevado, la causa probable es contención de recursos.
  • Si free indica swap activo > 20 % y iostat muestra alta latencia de disco, el bottleneck está en el almacenamiento.
  • Si ss -s revela miles de sockets en TIME_WAIT, el kernel está agotando la tabla de conexiones, lo que ralentiza nuevas sesiones SSH y HTTP.
  • Si ping muestra pérdida > 5 % o latencia > 200 ms, sospecha de problemas de red externa o de throttling.

3. Remediar según la causa

Contención de CPU / Memoria

  • Escala vertical la VM a una SKU con más vCPU o RAM (por ejemplo, pasar de D4ds_v4 a D8ds_v4).
  • Optimiza la aplicación: revisa procesos que consumen CPU (p.ej., compresión de logs, tareas cron).
  • Limita el número de workers en el servidor web (nginx, Apache) para que no saturen la CPU.
  • Desactiva swap o aumenta el tamaño del disco de swap si es necesario, pero la solución definitiva es añadir RAM.

I/O de disco

  • Cambia a un Premium SSD si la VM usa Standard HDD.
  • Habilita write caching y revisa la configuración de fsync en la base de datos o en los logs.
  • Usa tmpfs para directorios temporales intensivos en escritura.

Problemas de red

  • Aumenta el ancho de banda de la NIC (pasar de 1 Gbps a 2 Gbps si la SKU lo permite).
  • Configura Accelerated Networking (si la VM y la región lo soportan) para reducir latencia y pérdida de paquetes.
  • Revisa reglas de NSG y firewall que puedan estar inspeccionando tráfico excesivamente.
  • Si la IP pública es estática pero sigue presentando interrupciones, abre un ticket de soporte con Azure para confirmar que no hubo Live Migration inesperada.

Ajustes de kernel

  • Incrementa los límites de sockets:
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
  • Persiste los cambios en /etc/sysctl.conf y recarga con sysctl -p.

Mantenimiento de Azure

  • Programa maintenance windows y habilita Auto‑Scale para que, durante una migración, una segunda instancia tome el tráfico y evite interrupciones.

Cuándo aplicar esta solución

Aplica este enfoque cuando observes simultáneamente:

  • Retrasos de 2 s o más al abrir una sesión SSH.
  • Tiempo de respuesta HTTP > 30 s o errores de timeout.
  • Métricas de Azure que muestran picos de CPU, red o disco coincidentes con los incidentes.

No es necesario seguir todos los pasos si ya cuentas con un sistema de observabilidad que indique claramente la causa (por ejemplo, alertas de Azure que confirmen throttling de NIC). En esos casos, actúa directamente sobre la causa identificada.

Código

# Configuración rápida de sysctl para mejorar la tolerancia TCP
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

# Añadir al archivo de persistencia
cat <<EOF >> /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 4096
EOF
sysctl -p

Verificación

  1. Reproduce la carga (por ejemplo, con ab o hey contra el sitio) y verifica que los valores de CPU y red se mantengan bajo los umbrales configurados.
  2. Comprueba la latencia SSH: mide el tiempo de conexión con time ssh user@IP. Debe estar por debajo de 500 ms.
  3. Revisa los dashboards de Azure Monitor y Grafana; asegúrate de que no aparecen picos de Network Out o CPU durante la prueba.
  4. Ejecuta nuevamente los comandos de diagnóstico; los contadores de sockets y la pérdida de ping deben estar en rangos normales (< 1 % de pérdida).

Si los indicadores se mantienen estables y la aplicación responde sin interrupciones, la solución está confirmada.

Notas adicionales

  • Accelerated Networking no está disponible en todas las series de VM; verifica la compatibilidad antes de migrar.
  • Cuando uses IP estática, Azure sigue pudiendo mover la VM a otro host; la IP no cambia, pero la ruta sí, lo que puede generar breves interrupciones.
  • Mantén siempre una copia de seguridad de la configuración de sysctl antes de aplicar cambios; una configuración inadecuada puede empeorar la latencia.
  • Si la VM forma parte de un scale set, habilita health probes en el Load Balancer para que las instancias problemáticas se eliminen automáticamente.

Con una monitorización adecuada y ajustes proactivos en la VM y la red, los incidentes de SSH lento y caídas intermitentes de sitios en Azure pueden reducirse a una mínima ocurrencia, garantizando una experiencia estable tanto para administradores como para usuarios finales.