Mantenimiento de máquinas virtuales en Azure

Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Máquinas virtuales Windows ✔️ Conjuntos de escalado flexibles ✔️ Conjuntos de escalado uniformes

Azure actualiza periódicamente su plataforma para mejorar la confiabilidad, el rendimiento y la seguridad de la infraestructura de host para las máquinas virtuales. El objetivo de estas actualizaciones va desde la aplicación de revisiones a componentes de software en el entorno de hospedaje hasta la actualización de los componentes de red o la retirada de hardware.

Las actualizaciones raramente afectan a las máquinas virtuales hospedadas. Cuando las actualizaciones tienen algún efecto, Azure elige el método menos agresivo en las actualizaciones:

• Si la actualización no requiere reiniciar, la máquina virtual se pausa mientras se actualiza el host o la máquina virtual se migra en vivo a un host ya actualizado.

• Si la actualización requiere un reinicio, Azure le notifica el mantenimiento planeado. Asimismo, Azure proporciona un período de tiempo en el que puede iniciar el mantenimiento a la hora que le sea más conveniente. La ventana de automantenimiento depende del tipo de mantenimiento:

  • Retirada de hardware: la ventana de mantenimiento automático suele ser de 14 días.
  • Mantenimiento del host: la ventana de mantenimiento automático suele ser de 35 días, a menos que el mantenimiento sea urgente.

  Azure está invirtiendo en tecnologías para reducir el número de casos en los que el mantenimiento planeado de la plataforma requiere que las máquinas virtuales se reinicien. Para obtener instrucciones sobre cómo administrar el mantenimiento planeado, consulte Control de notificaciones de mantenimiento planeado mediante el CLI de Azure, PowerShell o el portal.

En esta página se describe cómo Azure realiza ambos tipos de mantenimiento. Para más información sobre eventos no planeados (interrupciones), consulte el artículo sobre la administración de la disponibilidad de máquinas virtuales para Windows o el artículo correspondiente para Linux.

Dentro de una máquina virtual, puede obtener una notificación sobre el próximo mantenimiento si usa Scheduled Events para Windows o para Linux.

Mantenimiento que no requiere un reinicio

La mayoría de las actualizaciones de plataforma no afectan a las máquinas virtuales del cliente. Cuando no es posible realizar una actualización sin causar impacto, Azure elige el mecanismo de actualización con menor impacto en las máquinas virtuales del cliente.

Cuando sea necesario realizar un mantenimiento que afecte a la máquina virtual, casi siempre se llevará a cabo mediante una pausa de la máquina virtual de menos de 10 segundos. En raras circunstancias, no más de una vez cada 18 meses para tamaños de máquina virtual de uso general, Azure usa un mecanismo que pausará la máquina virtual durante unos 30 segundos. Después de cualquier operación de pausa, el reloj de la máquina virtual se sincroniza automáticamente tras la reanudación.

El mantenimiento de conservación de memoria funciona para más del 90 por ciento de las máquinas virtuales de Azure. No funciona para la serie G, L, N y H. Para más información, consulte qué tamaños de máquina virtual admiten el mantenimiento de conservación de memoria. Azure usa cada vez más las tecnologías de migración en vivo y mejora el mecanismo de mantenimiento que conserva la memoria para así reducir la duración de la pausa.

Estas operaciones de mantenimiento, que no requieren reiniciar, se aplican a un dominio de error cada vez. Se detienen si reciben alguna señal de advertencia sobre el estado de las herramientas de monitorización de la plataforma. Las operaciones de mantenimiento que no requieren un reinicio pueden producirse simultáneamente en regiones emparejadas o Availability Zones. Para un cambio determinado, la implementación se secuenciará principalmente en Availability Zones y en los pares de regiones, pero puede haber superposición en la cola.

Estos tipos de actualizaciones pueden afectar a algunas aplicaciones. Cuando la máquina virtual se migra en vivo a otro host, es posible que algunas cargas de trabajo sensibles sufran una pequeña degradación del rendimiento en los pocos minutos anteriores a la pausa de la máquina virtual. Para preparar el mantenimiento de la máquina virtual y reducir el impacto durante el mantenimiento de Azure, intente usar Scheduled Events para Windows o Linux para estas aplicaciones.

Para un mayor control sobre todas las actividades de mantenimiento, incluidas las actualizaciones sin impacto y sin reinicio, puede crear una característica de configuración de mantenimiento. La creación de una configuración de mantenimiento ofrece la opción de omitir todas las actualizaciones de la plataforma y aplicarlas a la hora que elija. Para obtener más información, consulte Administración de las actualizaciones de la plataforma con configuraciones de mantenimiento.

Migración en vivo

La migración en vivo es una operación que no requiere un reinicio y que conserva la memoria para la máquina virtual. Provoca una pausa o inmovilización, y normalmente no dura más de 5 segundos. Excepto para las series G, L, N y H, todas las máquinas virtuales de infraestructura como servicio (IaaS) son aptas para la migración en vivo. La migración en vivo está disponible en la mayoría de las SKU de la serie M. Las máquinas virtuales aptas representan más del 90 por ciento de las máquinas virtuales IaaS que se implementan en la flota de Azure.

La plataforma Azure desencadena la migración en vivo en los escenarios siguientes:

• Mantenimiento planeado
• Error de hardware
• Optimizaciones de asignación

Algunos escenarios de mantenimiento planeado usan la migración en vivo, y se puede usar Scheduled Events para saber de antemano cuando se iniciarán las operaciones de migración en vivo.

La migración en vivo también se puede usar para mover máquinas virtuales cuando los algoritmos de Azure Machine Learning predicen un error de hardware inminente o optimización de asignaciones de máquinas virtuales. Para obtener más información sobre el modelado predictivo que detecta las instancias de hardware degradado, vea Improving Azure VM resiliency with predictive machine learning and live migration (Mejora de la resistencia de las máquinas virtuales de Azure con la migración en vivo y el aprendizaje automático predictivo). Las notificaciones de migración en vivo aparecen en los registros de Monitor y Service Health de Azure Portal, así como en Scheduled Events si utiliza estos servicios.

Resistencia de la conexión TCP durante la migración en vivo

Las aplicaciones que mantienen conexiones TCP de larga duración, como servidores de bases de datos, agentes de mensajes y capas de almacenamiento en caché, pueden experimentar interrupciones de conexión durante la migración en vivo. Aunque la pausa de la máquina virtual suele ser inferior a 5 segundos, el comportamiento de la pila TCP durante y después de la pausa puede ampliar el tiempo de recuperación de nivel de aplicación si no se aborda.

Cómo afecta la migración en vivo a las conexiones TCP:

• Durante la pausa, la VM en migración no reconoce los segmentos TCP en tránsito.
• El lado de envío (load balancer o sondeo de estado de cliente) comienza la retransmisión TCP con retroceso exponencial.
• Azure Standard Load Balancer envía un RST TCP a conexiones inactivas que superan el tiempo de espera de inactividad configurado. Sin embargo, para las conexiones activas con datos en tránsito, el Load Balancer no envía un paquete TCP RST durante la pausa de migración. La conexión permanece abierta, pero no responde, y el cliente no tiene ninguna señal inmediata de error.
• Sin el ajuste de nivel de aplicación, el comportamiento predeterminado de retransmisión tcp (tcp_retries2 = 15 en Linux) puede retrasar la detección de errores de conexión aproximadamente 15 minutos.

Reduzca el radio de explosión con implementaciones de varias instancias:

Antes de aplicar mitigaciones de nivel TCP, tenga en cuenta la línea base de arquitectura. La migración en vivo afecta a una sola máquina virtual a la vez en un conjunto de disponibilidad o un conjunto de escalado de máquinas virtuales. La propagación de conexiones entre varias instancias de back-end limita el impacto de cualquier evento de migración único:

• Un conjunto de escalado con tres instancias significa que cada evento de migración afecta como máximo a un tercio de las conexiones activas.
• La implementación en Availability Zones garantiza que las migraciones en distintas zonas no se superpongan.
• Los clientes con grupos de conexiones distribuidos entre varios back-end se recuperan más rápido porque las conexiones no afectadas siguen atendiendo las solicitudes inmediatamente.

Durante la pausa de la máquina virtual, los sondeos de estado del equilibrador de carga estándar de Azure dirigidos al back-end en pausa también fallan. El Load Balancer marca el backend como no operativo en aproximadamente 10 segundos (dos fallos consecutivos en la comprobación de estado con el intervalo predeterminado de 5 segundos) y deja de enrutar nuevas conexiones hacia él. Esta condición significa que las nuevas conexiones están protegidas de forma natural. Las mitigaciones de TCP descritas en este artículo abordan las conexiones existentes que ya se establecieron antes de que se iniciara la migración.

Mitigaciones recomendadas:

Las siguientes mitigaciones son complementarias. Cuando se implementan juntos, reducen el impacto de un evento de migración en vivo de minutos de tiempo de inactividad potencial a segundos de recuperación automática.

Mitigación 1: TCP_USER_TIMEOUT (detección más rápida)

TCP_USER_TIMEOUT controla cuánto tiempo espera el kernel para la confirmación de los datos transmitidos antes de declarar una conexión inactiva. Establecer esto en 30 segundos (30000 ms) por socket reduce significativamente el tiempo de detección.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Como alternativa, reduzca el recuento de retransmisiones en todo el sistema:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Consideraciones sobre Windows:

La TCP_USER_TIMEOUT opción de socket es específica de Linux. En Windows, el comportamiento de retransmisión tcp se controla de forma diferente:

• En Windows, el valor predeterminado es de 5 retransmisiones (TcpMaxDataRetransmissions), lo que ya proporciona aproximadamente de 25 a 50 segundos de tiempo de detección sin necesidad de realizar ajustes.
• Para reducir aún más el tiempo de detección en Windows, ajuste el registro:

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Con TcpMaxDataRetransmissions establecido en 3, el tiempo de detección se reduce a aproximadamente 10-20 segundos en función del tiempo de espera de retransmisión inicial.

Mitigación 2: Eventos programados (purga proactiva)

El servicio Scheduled Events proporciona un aviso previo antes de que comience una migración en vivo. Las aplicaciones pueden escuchar eventos Freeze y vaciar de forma proactiva las conexiones antes de que se produzca la pausa.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Un evento de migración en vivo aparece como:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Cuando se detecta un Freeze evento:

1. Deje de aceptar nuevas conexiones en el nodo afectado.
2. Purgar las conexiones existentes (indicar a los clientes que se vuelven a conectar a otros nodos).
3. Espera a que finalicen las operaciones en curso con un tiempo de espera limitado.
4. Opcionalmente, confirme el evento publicando el EventId.

Mitigación 3: ajuste del keepalive de TCP

Los sondeos keepalive tcp detectan conexiones que se vuelven inactivas después del evento de migración:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Con esta configuración, se detecta una conexión obsoleta inactiva en un plazo de 60 segundos (30 + 10 x 3). Las sondas de mantenimiento de conexión también cuentan como actividad a efectos del tiempo de espera de inactividad del Load Balancer estándar, lo que evita que este corte las conexiones inactivas de forma independiente.

Mitigación 4: lógica de reintento del lado cliente

La reconexión de nivel de aplicación y la lógica de reintento garantizan la recuperación independientemente del método de detección de errores:

1. Detecte el error de conexión (tiempo de espera, RST o conexión rechazada).
2. Cierre la conexión inactiva y quítela del grupo de conexiones.
3. Abra una nueva conexión al mismo nodo o a otro.
4. Vuelve a intentar la operación con retroceso exponencial.

En el caso de los SDK de base de datos y los grupos de conexiones, habilite comprobaciones de estado periódicas (por ejemplo, un ping ligero cada 10-15 segundos) para validar las conexiones de forma proactiva.

Configuración del grupo de conexiones:

Los grupos de conexiones que mantienen conexiones de larga duración se benefician de una configuración de duración máxima. Esta configuración impone el reciclaje periódico de la conexión, lo que garantiza que ninguna conexión acumule un riesgo ilimitado derivado de futuros eventos de migración:

Establecer una duración máxima de 30 minutos significa que incluso sin comprobaciones de estado activas, las conexiones se reemplazan naturalmente antes de que puedan acumular largos períodos de obsolescencia no detectados.

Supervisión y observabilidad:

Para detectar y medir el impacto de los eventos de migración en vivo en las conexiones TCP, use los métodos siguientes:

• Métrica de disponibilidad de máquina virtual de Azure Monitor (vista previa): desciende a 0 durante la pausa de la máquina virtual. Cree una regla de alerta en VmAvailabilityMetric con un umbral inferior a 1 para detectar eventos de migración.
• Registro de actividad de eventos programados: Los eventos de migración en vivo aparecen en el Registro de actividad bajo el proveedor Microsoft.Compute con el nombre de operación Microsoft.Compute/virtualMachines/liveMigration/action o como eventos Freeze cuando se consultan a través del Servicio de metadatos.
• Tasa de errores de conexión de nivel de aplicación: Supervise los restablecimientos de conexión TCP, los tiempos de espera y los recuentos de reconexión en las métricas de la aplicación. Un pico en los errores de conexión que se correlacionan con un descenso de disponibilidad de máquina virtual confirma el impacto de la migración.
• Contadores de retransmisión TCP: En Linux, supervise /proc/net/netstat el campo TCPTimeouts o use ss -ti para observar recuentos de retransmisión en sockets individuales. Las retransmisiones elevadas durante una ventana de mantenimiento conocida indican que las conexiones se vieron afectadas.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Establecer una línea base para estas métricas durante la operación normal facilita la cuantificación del impacto de los eventos de migración y validar que las mitigaciones funcionan según lo previsto.

Cargas de trabajo con tolerancia cero para la interrupción de la migración en vivo

Para las cargas de trabajo que no pueden tolerar ninguna interrupción debida a la migración en vivo, considere usar Azure Dedicated Hosts con Maintenance Configurations. Los hosts dedicados le permiten controlar cuándo se produce el mantenimiento a nivel de host, lo que elimina los eventos sorpresa de migración en directo.

Mantenimiento que requiere un reinicio

En el raro caso en que las máquinas virtuales deban reiniciarse para realizar el mantenimiento planeado, recibirá una notificación de antemano. El mantenimiento planeado tiene dos fases: la fase de autoservicio y una fase de mantenimiento programado.

Durante la fase de autoservicio, que normalmente tarda cuatro semanas, se inicia el mantenimiento en las máquinas virtuales. Como parte del autoservicio, puede consultar cada máquina virtual para ver su estado y el resultado de la última solicitud de mantenimiento.

Cuando inicia el mantenimiento de autoservicio, su máquina virtual se vuelve a implementar en un nodo ya actualizado. Como la máquina virtual se vuelve a implementar, se pierde el disco temporal y se actualizan las direcciones IP dinámicas públicas asociadas con la interfaz de red virtual.

Si surge un error durante el mantenimiento de autoservicio, la operación se detiene, la máquina virtual no se actualiza y se le ofrece la posibilidad de reintentar el mantenimiento de autoservicio.

Cuando finaliza la fase de autoservicio, comienza la fase de mantenimiento programado. Durante esta fase, puede seguir realizando consultas dentro de la fase de mantenimiento, pero no podrá iniciar el mantenimiento usted mismo.

Para obtener más información sobre la administración del mantenimiento que requiere un reinicio, consulte Control de las notificaciones de mantenimiento planeado mediante la CLI de Azure, PowerShell o el portal.

Consideraciones sobre disponibilidad durante el mantenimiento programado

Si decide esperar a la fase de mantenimiento programado, hay algunas cosas que debe tener en cuenta para mantener la máxima disponibilidad de las máquinas virtuales.

Regiones emparejadas

Cada región de Azure se empareja con otra región de la misma proximidad geográfica. Juntas, forman un par de regiones. Durante la fase de mantenimiento programado, Azure solo actualiza las máquinas virtuales en una sola región perteneciente a un par de regiones. Por ejemplo, al actualizar las máquinas virtuales de la zona Centro-norte de EE. UU., Azure no actualizará las máquinas virtuales de Centro-sur de EE. UU. al mismo tiempo. Sin embargo, otras regiones como Norte de Europa pueden estar en mantenimiento al mismo tiempo que el Este de EE. UU. Comprender cómo funcionan los pares de regiones puede ayudar a distribuir mejor las máquinas virtuales entre regiones. Para más información, consulte pares de regiones de Azure.

Zonas de disponibilidad

Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una región de Azure. Cada zona de disponibilidad está compuesta por uno o varios centros de datos equipados con suministro eléctrico, refrigeración y redes independientes. Para garantizar la resistencia, hay un mínimo de tres zonas independientes en todas las regiones habilitadas.

Una zona de disponibilidad es una combinación de un dominio de error y un dominio de actualización. Si crea tres o más máquinas virtuales en tres zonas de una región de Azure, las máquinas virtuales se distribuyen eficazmente en tres dominios de error y tres dominios de actualización. La plataforma Azure reconoce esta distribución entre dominios de actualización para asegurarse de que las máquinas virtuales de distintas zonas no se actualizan al mismo tiempo.

Cada actualización de la infraestructura se despliega zona por zona, dentro de una misma región. Sin embargo, puede haber un despliegue en curso en la zona 1 y un despliegue diferente en la zona 2 al mismo tiempo. No todas las implementaciones se serializan. Sin embargo, una sola implementación que requiere un reinicio únicamente implementa una zona cada vez para reducir el riesgo. En general, las actualizaciones que requieren un reinicio se evitan en la medida de lo posible y Azure intenta usar Migración en vivo o proporciona control a los clientes.

Conjuntos de escalado de máquinas virtuales

Los conjuntos de escalado de máquinas virtuales en el modo de orquestación flexible constituyen un recurso de proceso de Azure que le permite combinar la escalabilidad de los conjuntos de escalado de máquinas virtuales del modo de orquestación uniforme con las garantías de disponibilidad regionales de los conjuntos de disponibilidad.

Con la orquestación flexible, puede elegir si las instancias se distribuyen entre varias zonas o entre dominios de error dentro de una sola región.

Conjuntos de disponibilidad y conjuntos de escalado uniforme

Al implementar una carga de trabajo en máquinas virtuales de Azure, puede crear las máquinas virtuales dentro de un conjunto de disponibilidad para proporcionar alta disponibilidad a la aplicación. Mediante los conjuntos de disponibilidad, puede asegurarse de que durante una interrupción o en los eventos de mantenimiento que requieren un reinicio, al menos una máquina virtual estará disponible.

En un conjunto de disponibilidad, las máquinas virtuales individuales se distribuyen entre un máximo de 20 dominios de actualización. Durante el mantenimiento planeado, solo un dominio de actualización se ve actualizado en un momento determinado. Los dominios de actualización no necesariamente se actualizan de forma secuencial.

Los conjuntos de escalado de máquinas virtuales en el modo de orquestación uniforme constituyen un recurso de proceso de Azure que se puede usar para implementar y administrar un conjunto de máquinas virtuales idénticas como un recurso único. El conjunto de escalado se implementa automáticamente entre dominios de actualización, como las máquinas virtuales de un conjunto de disponibilidad. Al igual que con los conjuntos de disponibilidad, cuando se utilizan conjuntos de escalado uniforme, solo se actualiza un UD en cada momento dado durante el mantenimiento programado.

Para más información sobre la configuración de máquinas virtuales para alta disponibilidad, consulte el artículo sobre la administración de la disponibilidad de las máquinas virtuales para Windows o el artículo correspondiente para Linux.

Pasos siguientes

Para administrar el mantenimiento planeado, use el CLI de Azure, Azure PowerShell o el portal.