Compartir a través de

Descripción de un reinicio del sistema de una máquina virtual de Azure

  • Artículo

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

A veces, las máquinas virtuales de Azure se reinician sin motivo aparente, sin signos de que usted haya iniciado la operación. 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 las aplicaciones que se ejecutan en Azure del reinicio de las máquinas virtuales y el tiempo de inactividad es configurar la alta disponibilidad de las máquinas virtuales.

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 haya al menos una máquina virtual disponible que cumpla el 99,95 % del Acuerdo de Nivel de Servicio de Azure.

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

Información acerca de Resource Health

Azure Resource Health es un servicio que expone el estado de los recursos individuales de Azure y proporciona instrucciones para solucionar problemas. En un entorno en la 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 solucionar problemas. En concreto, el objetivo es reducir el tiempo que se tarda en determinar si la raíz del problema se encuentra en la aplicación o en un evento de la plataforma Azure. Para más información, consulte la introducción al uso de Resource Health.

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

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

Las alertas de estado de los recursos se envían en función de 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 los recursos que notifiquen este 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 una VM o se migra a un nuevo host, la plataforma de Azure no muestra el estado de la VM 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 las máquinas virtuales que no se muestran en el registro de actividad se filtran en la plataforma Azure para evitar que debido a errores transitorios se muestren tiempos de inactividad incorrectos a 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 gradual para ofrecer la mejor experiencia al 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 planeta para mejorar la confiabilidad, el rendimiento y la seguridad de la infraestructura de host que subyace debajo de 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 saber qué es el mantenimiento planeado de Azure y cómo afecta a la disponibilidad de las máquinas virtuales Linux, consulte los artículos que se enumeran aquí. En estos artículos se proporciona información general acerca del proceso del mantenimiento planeado de Azure y de cómo programarlo para reducir aún más sus efectos negativos.

Actualizaciones de conservación de memoria

Con esta clase de actualizaciones de Microsoft Azure, las máquinas virtuales en ejecución de los usuarios no se ven afectadas en absoluto. 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 conservan memoria se realizan con tecnología que permite la migración en vivo local. Cuando se está actualizando, el estado de la máquina virtual es En pausa, que conserva la memoria RAM mientras el sistema operativo host subyacente recibe las actualizaciones y revisiones necesarias. 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) no se aplican a más de un dominio de actualización a la vez.

Nota:

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

Acciones de reinicio o apagado iniciadas por el usuario

Si realiza un reinicio desde Azure Portal, Azure PowerShell, la interfaz de línea de comandos o la API de REST, el evento se encontrará en el registro de actividad de 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 diariamente las máquinas virtuales Windows y Linux por si faltan actualizaciones del sistema operativo. Defender for Cloud recupera una lista de actualizaciones críticas y de seguridad disponibles desde Windows Update o Windows Server Update Services (WSUS), dependiendo de qué servicio está configurado en una máquina virtual Windows. Defender for Cloud también comprueba las últimas actualizaciones de los sistemas Linux. Si falta una actualización del sistema en la máquina virtual, Defender for Cloud le recomienda que aplique las actualizaciones del sistema. Este proceso se controla a través de Defender for Cloud en Azure Portal. Tras la aplicación de algunas actualizaciones, puede ser necesario reiniciar la máquina virtual. Para más información, consulte Aplicar actualizaciones del sistema en Microsoft Defender for Cloud.

Al igual que los servidores locales, Azure no inserta las actualizaciones de Windows Update en las máquinas virtuales de Windows, ya que estas máquinas están diseñadas para que las administren los usuarios. No obstante, se recomienda dejar habilitada la configuración automática de Windows Update. La instalación automática de actualizaciones de Windows Update también puede provocar el reinicio tras su aplicación. Para más información, consulte Windows Update: preguntas frecuentes.

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

Hay otros casos en los que Azure puede 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 está hospedada en un servidor físico que se ejecuta en un centro de datos de Azure. El servidor físico ejecuta a un agente denominado al agente del host, además de otros componentes de Azure. Cuando estos componentes de software de Azure 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 si algo de esto sucede, identifica los errores subyacentes e implementa las actualizaciones una vez se ha implementado y probado 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 desencadena con la opción volver a implementar de la página de detalles de la máquina virtual o al detener y reiniciar la máquina virtual en Azure Portal.

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 las máquinas virtuales. Cuando un nodo host encuentra un problema, Azure intenta primero el método de recuperación menos perjudicial, que consiste en reiniciar el host. Si no es posible reiniciar el host o si el problema original está relacionado con el hardware, el servicio de plataforma sana todas las máquinas virtuales del host afectado a un nodo correcto. Aunque el reinicio de un host suele tener un impacto menor, las máquinas virtuales de recuperación de servicios pueden ser más complejas y lentas, en función del número de máquinas virtuales, sus restricciones de implementación y la disponibilidad de recursos locales. La recuperación del servicio se usa normalmente como último recurso para errores de hardware, ya que garantiza que las máquinas virtuales sigan funcionando sin tiempo de inactividad significativo.

Si un servidor host no se puede reiniciar, Azure inicia una acción de recuperación automática para que el host defectuoso salga de la rotación para realizar una investigación más detallada. Durante este proceso de recuperación automática, todas las máquinas virtuales del host se reubican automáticamente en otro servidor host correcto. Aunque este proceso se completa normalmente en un plazo de 15 minutos, 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. Para más información sobre cómo Azure controla estos escenarios, consulte Recuperación del servicio: recuperación automática de máquinas virtuales.

Mantenimiento no planeado

En contadas ocasiones, el equipo de operaciones de Azure podría necesitar realizar actividades de mantenimiento para garantizar el buen 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

Bloqueos en la máquina virtual

Las máquinas virtuales podrían reiniciarse debido a problemas internos. 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 determinar el motivo del bloqueo, consulte los registros de la aplicación y del sistema (máquinas virtuales Windows) y los registros de serie (máquinas virtuales Linux).

Las máquinas virtuales de Azure usan discos virtuales para el sistema operativo y el almacenamiento de datos que se hospeda en la infraestructura de Azure Storage. Cada vez que la disponibilidad o la conectividad entre la máquina virtual y los discos virtuales asociados se ven afectadas durante más de 120 segundos, la plataforma Azure realiza un apagado forzado de las máquinas virtuales para evitar que se dañ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 circunstancias excepcionales, un problema muy generalizado puede afectar a varios servidores de un centro de datos de Azure. En ese caso, el equipo de Azure envía notificaciones por correo electrónico a las suscripciones afectadas. Verá el estado de las interrupciones actuales y de los incidentes anteriores tanto en el panel de estado de los servicios de Azure como en Azure Portal.

Diagnosticar reinicios de VM

Puede utilizar la hoja Diagnosticar y resolver en la hoja de la VM para ejecutar 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 el volcado de memoria y póngase en contacto con el soporte técnico.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.