Mantenimiento del host en la nube y migración en vivo Cloud host maintenance / live migration
ID de la causa nic-host-maintenance · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Cuando el proveedor de nube hace mantenimiento de un servidor físico (host), mueve las máquinas virtuales a otro host (migración en vivo) o las pausa un momento. Mientras tanto, todo el servidor se detiene y, si la pausa es larga, las conexiones se cortan.
Por qué El proveedor mueve la máquina virtual a otro host o la pausa un momento por mantenimiento del host o por una avería prevista → Efecto Durante el traslado, la CPU, la memoria y la red van más lentas, y al final la máquina virtual se detiene por completo un instante (de menos de 1 segundo a unos 30 segundos, según el proveedor y el método) → En pantalla Todos los jugadores del servidor se congelan a la vez y luego hay cámara rápida y teletransporte; si la pausa dura más que el timeout, desconexión masiva
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Externo (Externo)
Tareas (Equipo de desarrollo)
Usar timeouts que aguanten pausas de unos segundos, poner un límite a los ticks que se recuperan tras una pausa, calcular el tiempo transcurrido con un reloj monotónico, tener un procedimiento que guarde el progreso y mueva a los jugadores a otro servidor al recibir el aviso de mantenimiento.
Tareas (Equipo de infraestructura)
Suscribirse a los avisos de mantenimiento y poner alertas (Google Cloud maintenance-event, eventos programados de AWS y AWS Health, Azure Scheduled Events), reemplazar el servidor de antemano en horas con pocos jugadores al recibir un aviso, ajustar la hora del mantenimiento cuando el proveedor lo permita (Azure Maintenance Configuration, eventos programados de AWS según el tipo), cruzar los registros de mantenimiento con los de incidentes.
Tareas (Externo)
Consultar al proveedor de nube el calendario de mantenimiento y su alcance, reportar las instancias que se pausan una y otra vez.
Cifras de referencia
Según Google Compute Engine, la pausa de la migración en vivo suele ser mucho más corta que 1 segundo, y durante la pausa el reloj del sistema puede saltar hasta 5 segundos hacia delante. El valor maintenance-event de los metadatos cambia 60 segundos antes del traslado (si se consultó al menos una vez antes). En Azure, el mantenimiento que no requiere reinicio casi siempre detiene la VM menos de 10 segundos y, rara vez (no más de una vez cada 18 meses en los tamaños de uso general), unos 30 segundos; la migración en vivo no suele pasar de 5 segundos. Azure Scheduled Events avisa de estas pausas (Freeze) con al menos 15 minutos de antelación. Pero si el hardware del host falla de repente, la recuperación empieza enseguida, sin aviso.
En el gráfico
Hueco y luego ráfaga · Paquetes enviados/recibidos del servidor, intervalo de tick
Dónde mirar
Cruzar la hora de la pausa con los registros del proveedor. Google Cloud: compute.instances.migrateOnHostMaintenance en los logs de auditoría; AWS: eventos programados en describe-instance-status y AWS Health; Azure: Microsoft.Compute/virtualMachines/liveMigration/action en el registro de actividad (Activity Log) y la hora en que la métrica de disponibilidad de la VM (VmAvailabilityMetric) cayó a 0. Dentro del servidor, ver si las métricas y los logs tienen un hueco durante la pausa y si el reloj saltó justo después (logs de sincronización horaria)
Se confirma si
La hora a la que se detuvo todo el servidor coincide con un mantenimiento o una migración que el proveedor tiene registrados, y durante esos segundos todas las métricas y los logs del servidor están vacíos
Se descarta si
Si no aparece en los registros del proveedor y se repiten pausas cortas a menudo, apunta a “CPU steal (máquinas virtuales)”. Si el log del kernel tiene registros de reinicio (reset) de la NIC, a “Problemas de driver y firmware de la NIC”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
AWS avisa mediante eventos programados. system-reboot significa que la instancia se reiniciará y pasará a un host nuevo; system-maintenance significa que un mantenimiento de red o de alimentación puede afectarla un momento. Aunque la pausa dure unos segundos, los clientes que no recibieron el ACK de los paquetes enviados al servidor en ese tiempo van duplicando la espera de retransmisión, así que la conexión TCP puede seguir detenida un rato más después de la pausa (“RTO de TCP y backoff exponencial”). Al despertar, el reloj puede saltar y provocar un “Salto del reloj del sistema (step de NTP)”, y los health checks del balanceador de carga pueden fallar y sacar ese servidor durante un tiempo. Las instancias que no se pueden mover (como las instancias bare metal de Google Cloud) se detienen o se reinician durante el mantenimiento.
Fuentes
Live migration process during maintenance eventsGoogle Cloud La pausa de la migración en vivo suele ser mucho más corta que 1 segundo; durante la pausa el reloj del sistema salta hasta 5 segundos hacia delante; durante el traslado baja un momento el rendimiento de disco, CPU, memoria y red; las VM que no hacen migración en vivo se apagan durante el mantenimiento (las instancias bare metal no la admiten)
Query metadata server for maintenance event noticesGoogle Cloud El valor maintenance-event de los metadatos cambia 60 segundos antes de la migración en vivo (si la VM está configurada para migración en vivo y el valor se consultó al menos una vez desde el último mantenimiento)
Scheduled events for Amazon EC2 instancesAWS Tipos de eventos programados (system-reboot: reinicio y traslado a un host nuevo; system-maintenance: efecto breve por mantenimiento de red o de alimentación), aviso por correo y por AWS Health, consulta con describe-instance-status, hora ajustable según el tipo
Maintenance and updatesMicrosoft Azure El mantenimiento sin reinicio casi siempre pausa menos de 10 s, rara vez (no más de una vez cada 18 meses en los tamaños de uso general) unos 30 s, y la migración en vivo suele durar 5 s o menos; tras la pausa el reloj se sincroniza solo; las conexiones TCP largas pueden cortarse, o la recuperación puede tardar más porque el otro extremo retransmite con backoff exponencial los datos enviados a la VM pausada; los health checks del balanceador de carga la marcan en mal estado en unos 10 s; se confirma con Microsoft.Compute/virtualMachines/liveMigration/action en el registro de actividad y con VmAvailabilityMetric, que cae a 0 durante la pausa; con Maintenance Configuration se elige cuándo se aplica
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (pausa de unos segundos; la CPU y la red pueden detenerse) se avisa con al menos 15 minutos de antelación; si falla el hardware del host, la recuperación empieza enseguida, sin periodo de aviso