Compartir a través de


Comprender un reinicio del sistema para una VM de Azure

Se aplica a: ✔️ máquinas virtuales Linux ✔️ máquinas virtuales Windows

Resumen

Las máquinas virtuales de Azure (VMs) pueden reiniciarse a veces sin motivo aparente, sin evidencia de que usted haya iniciado la operación de reinicio. En este artículo se enumeran las acciones y los eventos que pueden hacer que las máquinas virtuales se reinicien y se proporciona información acerca de cómo evitar los problemas de reinicio inesperado o reducir su efecto.

Configuración de las máquinas virtuales para que tengan alta disponibilidad

La mejor manera de proteger una aplicación que se ejecuta en Azure contra los reinicios de la máquina virtual y el tiempo de inactividad es configurar las máquinas virtuales para lograr una alta disponibilidad.

Para proporcionar este nivel de redundancia a la aplicación, se recomienda agrupar dos máquinas virtuales, o más, en un conjunto de disponibilidad. Esta configuración garantiza que durante un evento de mantenimiento planeado o no planeado, al menos una máquina virtual está disponible y cumple el 99,95 % Azure SLA.

Para más información sobre los conjuntos de disponibilidad, consulte Administrar la disponibilidad de las máquinas virtuales.

información de Resource Health

Azure Resource Health es un servicio que expone el estado de los recursos de Azure individuales y proporciona instrucciones útiles para solucionar problemas. En un entorno de nube en el que no es posible acceder directamente a servidores o elementos de infraestructura, el objetivo de Resource Health es reducir el tiempo que dedica a la solución de problemas. En concreto, el objetivo es reducir el tiempo que dedica a determinar si la raíz del problema se encuentra en la aplicación o en un evento dentro de la plataforma Azure. Para obtener más información, consulte Comprender y utilizar Resource Health.

Si Azure tiene más información sobre la causa principal de una falta de disponibilidad iniciada por la plataforma para una máquina virtual, esa información puede publicarse en resource health hasta 72 horas después de la falta de disponibilidad inicial.

Tiempos de inactividad de las VM que faltan en el registro de actividad

Alertas de Salud de Recursos se basan en la información del Registro de actividad. En algunos casos, es posible que los tiempos de inactividad de las máquinas virtuales no se muestren en el registro de actividad. Si el tiempo de inactividad no aparece en el registro de actividad, no se enviarán alertas de estado de recursos para el tiempo de inactividad. El tiempo de inactividad sigue siendo visible en Resource Health.

Estos son los casos en los que los tiempos de inactividad de las máquina virtual no se muestran en el registro de actividades:

  • Cuando se crea o migra una máquina virtual a un nuevo host, Azure plataforma no muestra el estado de la máquina virtual correctamente y el estado cambia a Desconocido. Solo después de establecer todos los procesos de conectividad de red y de nodos, el estado de la máquina virtual cambia a Disponible. El periodo prolongado del estado Desconocido se filtra fuera del registro de actividades.
  • Cuando el estado de disponibilidad de la VM cambia de Disponible a No disponible y, luego, vuelve a Disponible en menos de 35 segundos, el tiempo de inactividad no se muestra en el registro de actividad. Este caso no se producirá si se envía un tiempo de inactividad correlacionado en los 15 minutos anteriores a que se produzca la primera transición.
  • Si el estado de la VM cambia de un estado a Desconocido y, luego, vuelve al estado original, el estado Desconocido intermitente y las transiciones relacionadas se filtran fuera del registro de actividades.

Los tiempos de inactividad de la máquina virtual que no se muestran en el registro de actividad se filtran en el lado de la plataforma de Azure para evitar que los errores transitorios muestren tiempos de inactividad incorrectos para los clientes. Con las inversiones en curso para la calidad del estado de las VM, es posible que los filtros ya no sean necesarios y podrían hacer que los cambios rápidos en el estado de las VM no se notifiquen. Microsoft está trabajando en un plan de eliminación progresiva para ofrecer la mejor experiencia para el cliente.

Acciones y eventos que pueden hacer que la máquina virtual se reinicie

Mantenimiento planeado

Microsoft Azure realiza periódicamente actualizaciones en todo el mundo para mejorar la confiabilidad, el rendimiento y la seguridad de la infraestructura de host que subyace a las máquinas virtuales. Muchas de esas actualizaciones, entre las que se incluyen las de conservación de memoria, se realizan sin que afecten a las máquinas virtuales ni a los servicios en la nube.

Sin embargo, algunas de ellas requieren un reinicio. En estos casos, las máquinas virtuales se apagan mientras se revisa la infraestructura y luego se reinician.

Para comprender qué es Azure mantenimiento planeado y cómo puede afectar a la disponibilidad de las máquinas virtuales Linux, consulte los artículos que se enumeran aquí. Los artículos proporcionan información general sobre el proceso de mantenimiento planeado de Azure y cómo planificar el mantenimiento para reducir aún más el impacto.

Actualizaciones de preservación de memoria

Para esta clase de actualizaciones en Microsoft Azure, los usuarios no experimentan ningún impacto en sus máquinas virtuales en ejecución. Muchas de estas actualizaciones son componentes o servicios que se pueden actualizar sin interferir con la instancia en ejecución. Algunas son actualizaciones de la infraestructura de la plataforma en el sistema operativo host que se pueden aplicar sin necesidad de que se reinicien las máquinas virtuales.

Estas actualizaciones que preservan la memoria se realizan con tecnología que permite la migración en vivo en el lugar. Cuando se está actualizando, el estado de la máquina virtual es En pausa, Este estado preserva la memoria en RAM mientras el sistema operativo host subyacente recibe las actualizaciones y parches necesarios. La máquina virtual suele reanudarse en menos de 30 segundos después de haberse puesto en pausa. Tras la reanudación, el reloj de la máquina virtual se sincroniza automáticamente.

Debido al período breve de pausa, la implementación de actualizaciones mediante este mecanismo permite que las máquinas virtuales casi no resulten afectadas. Sin embargo, no todas las actualizaciones pueden implementarse de esta manera.

Las actualizaciones de varias instancias (para las máquinas virtuales de un conjunto de disponibilidad) se aplican a un dominio de actualización cada vez.

Nota:

Durante este método de actualización, las máquinas Linux que tienen versiones antiguas del kernel se ven afectadas por un pánico del kernel. Para evitar este problema, actualice el kernel a la versión 3.10.0-327.10.1 o a una posterior. Para obtener más información, consulte Una máquina virtual de Linux de Azure en un kernel basado en la versión 3.10 entra en pánico después de una actualización de nodo de host.

Acciones de reinicio o apagado iniciadas por el usuario

Si realiza un reinicio desde el portal de Azure, Azure PowerShell, interfaz de línea de comandos o API REST, puede encontrar el evento en el registro de actividad Azure.

Si realiza la acción desde el sistema operativo de la máquina virtual, el evento se encontrará en los registros del sistema.

Otros escenarios que suelen provocar el reinicio de la máquina virtual incluyen varias acciones de cambio de configuración. Generalmente aparece un mensaje de advertencia que indica que la ejecución de una acción determinada provoca el reinicio de la máquina virtual. Por ejemplo, las operaciones de cambio de tamaño de máquina virtual, el cambio de la contraseña de la cuenta administrativa y la configuración de una dirección IP estática.

Microsoft Defender for Cloud y Windows Update

Microsoft Defender for Cloud supervisa las máquinas virtuales Linux y Windows diarias para las actualizaciones de sistema operativo que faltan. Defender for Cloud recupera una lista de actualizaciones críticas y de seguridad disponibles de Windows Update o Windows Server Update Services (WSUS), en función de qué servicio esté configurado en una máquina virtual de Windows. Defender for Cloud también comprueba las actualizaciones más recientes de los sistemas Linux. Si la máquina virtual no tiene una actualización del sistema, Defender for Cloud recomienda aplicar las actualizaciones del sistema. La aplicación de estas actualizaciones del sistema se controla a través del Defender for Cloud en el portal de Azure. Tras la aplicación de algunas actualizaciones, puede ser necesario reiniciar la máquina virtual. Para obtener más información, consulte Aplicar actualizaciones del sistema en Microsoft Defender for Cloud.

Al igual que los servidores locales, Azure no empuja actualizaciones de Windows Update a máquinas virtuales de Windows, ya que estas máquinas están diseñadas para ser administradas por sus usuarios. Sin embargo, se recomienda dejar habilitada la configuración de Windows Update automática. La instalación automática de actualizaciones de Windows Update también puede provocar que se produzcan reinicios después de aplicar las actualizaciones. Para obtener más información, consulte Windows Update preguntas más frecuentes.

Otras situaciones que afectan a la disponibilidad de la máquina virtual

Hay otros casos en los que Azure podrían suspender activamente el uso de una máquina virtual. Antes de que se realice esta acción, se le notificará para que pueda resolver los problemas subyacentes. La vulneración de la seguridad y la expiración de las formas de pago son ejemplos de problemas que afectan a la disponibilidad de las máquinas virtuales.

Errores en el servidor host

La máquina virtual se hospeda en un servidor físico que se ejecuta dentro de un centro de datos de Azure. El servidor físico ejecuta un agente denominado Agente host además de algunos otros componentes de Azure. Cuando estos Azure componentes de software en el servidor físico dejan de responder, el sistema de supervisión desencadena un reinicio del servidor host para intentar la recuperación. En muchos casos, la VM volverá a estar disponible en 10-15 minutos en el mismo host que antes.

Los errores en el servidor suelen deberse a errores de hardware, como un disco duro o una unidad de estado sólido. Azure supervisa continuamente estas apariciones, identifica los errores subyacentes y implementa las actualizaciones después de implementar y probar la mitigación.

Puesto que algunos errores en el servidor host pueden ser específicos de ese servidor, para mejorar una situación en la que una máquina virtual se reinicia de manera repetitiva es preciso implementar la máquina virtual manualmente en otro servidor host. Esta operación se puede desencadenar mediante la opción redeploy en la página de detalles de la máquina virtual o deteniendo y reiniciando la máquina virtual en el portal de Azure.

Recuperación automática

La plataforma Azure está diseñada para controlar los problemas del nodo host con un impacto mínimo en el rendimiento de la máquina virtual. Cuando un nodo host encuentra un problema, Azure primero intenta el método de recuperación menos perjudicial, que consiste en reiniciar el host. Si no es posible reiniciar el host o el problema está relacionado con el hardware, Azure inicia una acción de recuperación automática para que el host defectuoso salga de la rotación para una investigación más detallada. Como parte de esta recuperación automática, un proceso conocido como recuperación del servicio reubicará automáticamente todas las máquinas virtuales del host defectuoso en otra correcta. Normalmente, este proceso se completa en un plazo de 15 minutos, aunque el tiempo de recuperación puede variar en función de factores como el tamaño de memoria del host y los métodos de recuperación usados. La recuperación del servicio se usa normalmente como último recurso para los errores de hardware para asegurarse de que las máquinas virtuales siguen funcionando sin tiempo de inactividad significativo.

Para obtener más información sobre cómo Azure controla estos escenarios, consulte Service Healing : recuperación automática de Virtual Machines.

Mantenimiento no planeado

En raras ocasiones, es posible que el equipo de operaciones de Azure necesite realizar actividades de mantenimiento para garantizar el estado general de la plataforma Azure. Este comportamiento podría afectar a la disponibilidad de las máquinas virtuales y suele generar la misma acción de recuperación automática que se ha descrito.

Los mantenimientos no planeados incluyen lo siguiente:

  • Desfragmentación urgente de nodos
  • Actualizaciones urgentes de los conmutadores de la red

Fallos de la máquina virtual

Es posible que las máquinas virtuales se reinicien debido a problemas internos de máquina virtual o problemas de hardware, como un problema de disco del sistema operativo, como se ha descrito anteriormente. La carga de trabajo o el rol que se ejecuta en la máquina virtual podría desencadenar una comprobación de errores en el sistema operativo invitado. Para encontrar el motivo del bloqueo, compruebe los registros del sistema y de la aplicación para máquinas virtuales de Windows y los registros de serie de las máquinas virtuales de Linux. La recopilación de un volcado de memoria suele ser la mejor manera de identificar la causa principal.

Para obtener más información, consulte los artículos siguientes:

Las máquinas virtuales de Azure dependen de discos virtuales para el sistema operativo y el almacenamiento de datos hospedado en la infraestructura de Azure Storage. Siempre que la disponibilidad o conectividad entre la máquina virtual y los discos virtuales asociados se vea afectada durante más de 180 segundos, la plataforma Azure realiza un apagado forzado de las máquinas virtuales para evitar daños en los datos. Una vez que se ha restaurado la conectividad del almacenamiento, las máquinas virtuales se vuelven a encender automáticamente. Las máquinas puede que solo permanezcan cinco minutos apagadas, pero también puede permanecer así mucho más tiempo.

Otros incidentes

En raras circunstancias, un problema generalizado puede afectar a varios servidores de un centro de datos de Azure. Si se produce este problema, el equipo de Azure envía notificaciones por correo electrónico a las suscripciones afectadas. Puede comprobar el panel Azure Service Health y el portal de Azure para ver el estado de interrupciones continuas y incidentes anteriores.

Diagnóstico de reinicios de máquina virtual

Puede usar el panel Diagnosticar y Resolver en el panel de VM para realizar diagnósticos adicionales. Esto puede revelar razones más específicas del reciente reinicio de su VM. Si hay algún problema del sistema operativo invitado, recopile un volcado de memoria y póngase en contacto con el soporte técnico.