Reinicios de instancias de rol causados por actualizaciones del sistema operativo de máquina virtual de Azure

En este artículo se describen los efectos de las actualizaciones del sistema operativo (SO) de máquina virtual (VM) de Microsoft Azure al reiniciar instancias de rol. Contiene detalles sobre las programaciones de actualización del so y el agente invitado, los impactos y requisitos del servicio, la notificación, la detección y cómo resolver problemas comunes.

Programaciones de actualización

Aproximadamente mensualmente, Microsoft publica una nueva versión del sistema operativo invitado para máquinas virtuales de plataforma como servicio (PaaS) de Azure. La programación exacta varía y la tendencia histórica se puede ver en las versiones del sistema operativo invitado de Azure y en la matriz de compatibilidad del SDK. Durante esta implementación, Azure Fabric Controller realiza dos pasadas (un paso del sistema operativo host y un paso del sistema operativo invitado) a través de todos los centros de datos. Una actualización periódica del agente invitado de Azure también se ejecuta dentro de la máquina virtual.

En las secciones siguientes se proporcionan más detalles sobre los dos pases de actualización y la actualización del agente invitado.

Paso 1: Sistema operativo host

El primer paso actualiza el sistema operativo host. El sistema operativo host reinicia las instancias de rol y el controlador de tejido se asegura de que solo se reinicien las instancias de un dominio de actualización a la vez. Durante este reinicio, las instancias de rol pasan por el proceso de apagado estándar. A continuación, se ejecuta el RoleEnvironment.OnStop evento para darle la oportunidad de apagar correctamente la instancia.

La actualización del sistema operativo host puede tardar varios días en coordinar las actualizaciones en todos los distintos servicios hospedados y dominios de actualización dentro de un centro de datos. Normalmente, diferentes instancias de la implementación se actualizan con varias horas de diferencia.

Para obtener más información sobre el proceso de actualización del sistema operativo host, consulte el artículo de blog actualizaciones de host de Azure: por qué, cuándo y cómo .

Paso 2: SO invitado

Una vez que el sistema operativo host finaliza la actualización en el centro de datos, el sistema operativo invitado se actualiza para los servicios configurados para usar versiones automáticas del sistema operativo invitado. Esta actualización continúa mediante reglas de dominio de actualización estándar para el servicio. La máquina virtual se reinicia y la partición de Windows (la unidad D) se vuelve a crear mediante el sistema operativo actualizado.

El proceso de actualización del sistema operativo invitado es mucho más rápido que la actualización del sistema operativo host. Esto se debe a que el tejido solo tiene que coordinar la actualización dentro del servicio hospedado y los dominios de actualización. La duración del proceso de actualización del sistema operativo invitado para el servicio depende en gran medida de los siguientes factores:

• Número de instancias de rol
• Número de dominios de actualización
• Cuánto tiempo tarda el servicio en apagarse (Stopping y OnStop eventos)
• Cuánto tiempo tarda el servicio en iniciarse (tareas de inicio y el OnStart evento)

Agente invitado

El agente invitado de Azure se actualiza aproximadamente mensualmente. Cuando se actualiza el agente invitado, se producen las siguientes acciones:

• El proceso de host que ejecuta el rol (normalmente WaWorkerHost o WaWebHost) se cierra correctamente.
• El agente invitado se actualiza a sí mismo.
• El proceso de host se inicia de nuevo.

Para obtener más información sobre el proceso del agente invitado y cómo interactúa con el servicio, consulte Flujo de trabajo de la arquitectura de máquina virtual clásica de Windows Azure.

Impactos y requisitos del servicio

En la lista siguiente se describen los impactos y requisitos del servicio en la nube:

• Si alguno de los roles tiene solo una instancia, el servicio podría experimentar un tiempo de inactividad. Debe tener al menos dos instancias de cada rol porque el contrato de nivel de servicio (SLA) requiere un tiempo de actividad del 99,95 por ciento.

• Espere que las instancias de rol se reinicien para la actualización del sistema operativo host aproximadamente una vez al mes. Si tiene actualizaciones automáticas del sistema operativo invitado, espere que las instancias se reinicien de nuevo. Normalmente, los reinicios tienen varias horas de diferencia. Sin embargo, este período de tiempo puede cambiar en función de la composición de los distintos servicios que existen dentro de un centro de datos.

• El rol tiene que cumplir las reglas que rigen las actualizaciones del sistema operativo host. En concreto, las instancias de rol deben alcanzar el estado en un Ready plazo de 30 minutos después de iniciar las tareas de inicio. Para obtener más información sobre esta limitación, vea Cómo se realiza una actualización.

• La actualización del sistema operativo host provoca un reinicio de la instancia de rol y la actualización del sistema operativo invitado provoca el equivalente de una nueva imagen imagen de la instancia. Debido a estos eventos, las instancias de rol deben poder controlar los procedimientos siguientes:

  • Restart
  • Reimage
  • Reciclar

Notificación

Actualmente, la plataforma Azure no ofrece notificaciones proactivas cuando se está produciendo una actualización del sistema operativo. Las instancias de rol recibirán un RoleEnvironment.Stopping evento antes de que se apaguen. Puede usar ese evento para finalizar correctamente cualquier trabajo que esté realizando la instancia de rol o para notificar a un administrador que se está cerrando una instancia.

Puede suscribirse a la fuente RSS Novedades del sistema operativo de Azure. Esta fuente debe actualizarse el mismo día en que las actualizaciones del sistema operativo comienzan a implementarse en el centro de datos. Normalmente, la fuente no proporciona notificaciones proactivas avanzadas, pero le ayuda a identificar cuándo se producen las actualizaciones. El proceso de actualización puede tardar varios días en completarse. Por lo tanto, es posible que tenga que esperar uno o más días entre el momento en que se actualiza la fuente RSS y el servicio hospedado comienza a actualizarse.

La lista de versiones del sistema operativo invitado de Azure y la lista de versiones del sistema operativo que están disponibles para su selección en el Azure Portal se actualizan normalmente una vez completada la implementación del sistema operativo invitado. No debe usar la entrada más reciente de estas listas como indicación de cuándo están en curso las actualizaciones del sistema operativo.

Detección

Actualmente, no hay ninguna manera directa de detectar una actualización del sistema operativo host. Sin embargo, puede ver la evidencia del reinicio dentro de los registros de la máquina virtual. Para ello, utilice una de las acciones siguientes:

• En la aplicación Visor de eventos, busque en los registros de eventos del sistema el origen de eventos USER32, identificador de evento 1074. Este evento contiene el siguiente mensaje:

  El proceso D:\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) ha iniciado el apagado del equipo RD00155D50206D en nombre del usuario NT AUTHORITY\SYSTEM por el siguiente motivo: Apagado de API heredada

  Este mensaje indica que el agente invitado de Tejido de Azure (WaAppAgent.exe) inició un apagado de la máquina virtual.

• En un editor de texto, busque en un archivo de registro de tiempo de ejecución del agente de aplicación antiguo (AppAgentRuntime.log.old) un _Context_Start mensaje en el que sea Context igual a .StopContainer() Para obtener más información sobre cómo examinar las entradas de contexto en el registro en tiempo de ejecución del agente de la aplicación, consulte Solución de problemas del escenario 6: reciclaje de roles después de ejecutarse durante algún tiempo en el archivo de blog de Azure.

Problemas y soluciones comunes

En las secciones siguientes se describen algunos problemas comunes que implican reinicios de instancias de rol y cómo resolverlos. Para obtener más información sobre los procesos que se ejecutan y la ubicación de los archivos de registro que puede usar para solucionar problemas, consulte Flujo de trabajo de la arquitectura de máquina virtual clásica de Windows Azure.

Problema 1: Las tareas de inicio o el código no se pueden ejecutar la segunda vez después de reiniciar un sistema operativo host

Las tareas de inicio o el código de la OnStart función o Run pueden producir un error la segunda vez después de reiniciar un sistema operativo host. Se supone que el reinicio invocará las tareas de inicio para que se vuelvan a ejecutar. Este error impide que la instancia de rol alcance el Ready estado.

¿Qué ocurre si está haciendo algo en una tarea de inicio y, a continuación, ejecuta un comando que devuelve un error después de que se ejecute la segunda vez? En este caso, se producirá un error en la tarea de inicio y se iniciará el reciclaje de la instancia de rol. Por ejemplo, si usa el comando set config de APPCMD para agregar una sección de configuración en Internet Information Services (IIS), el comando producirá un error en su segunda ejecución. El comando genera el mensaje de error"Nuevo objeto que falta atributos necesarios. No se puede agregar una entrada de colección duplicada de tipo..." A continuación, la instancia de rol comienza a reciclarse.

Solución 1: Conectarse a la máquina virtual y depurar el error de inicio o código de forma remota

Para solucionar este tipo de error, use el Protocolo de Escritorio remoto (RDP) para conectarse a la máquina virtual de forma remota. Examine los registros de eventos en busca de errores y compruebe si hay errores en la tarea de inicio en el archivo de WaHostBootstrapper.log . Durante el proceso de desarrollo y pruebas típico, debe iniciar de forma proactiva un reinicio de las instancias de rol desde el Azure Portal. Este paso le ayuda a probar el servicio para asegurarse de que funciona correctamente en este escenario.

Una corrección común para los errores de tarea de inicio es agregar un exit /b 0 comando al final del script de tarea de inicio. Este comando de salida finaliza el script mediante un código de salida que indica que se ha realizado correctamente. Para obtener más información sobre por qué es necesario este comando, consulte Configuración y ejecución de tareas de inicio para un servicio en la nube de Azure (clásico).

Problema 2: La tarea de inicio o el código no se ejecutan después de que se vuelva a crear la imagen de la partición de Windows

La partición de Windows (unidad D) suele ser donde se almacenan las instalaciones del programa y los cambios del Registro. Durante la parte del sistema operativo invitado de una actualización, se vuelve a crear una imagen de la partición de Windows. Esto puede hacer que estas instalaciones y cambios se pierdan. Si el código de inicio supone erróneamente que todavía existen determinados cambios en el Registro después de que se vuelva a crear la imagen por imagen de la partición de Windows, es posible que la instancia de rol no funcione correctamente. Este error impide que la instancia de rol alcance el Ready estado.

Por ejemplo, la tarea de inicio podría realizar un cambio en el Registro. A continuación, almacena un registro de ese cambio en la unidad C o E para asegurarse de que el cambio del Registro no se ejecuta una segunda vez. Sin embargo, el cambio del Registro en la unidad D se perderá debido al reimaging y la tarea de inicio no restaurará ese cambio del Registro porque la tarea no cree que sea necesaria. El cambio del Registro que falta puede provocar un error en el resto de la tarea de inicio.

Solución 2: Pruebe la nueva imagen de las instancias de rol desde el Azure Portal

Durante el proceso de desarrollo y pruebas típico, debe iniciar proactivamente una nueva imagen de las instancias de rol desde el Azure Portal. Este paso le ayuda a probar el servicio y a asegurarse de que funciona correctamente en este escenario.

Problema 3: El código de inicio tarda más de 30 minutos en finalizar

Si el código de inicio tarda más de 30 minutos en finalizar, es posible que tenga más de una instancia de rol fuera de servicio al mismo tiempo. Este escenario suele producirse cuando una tarea de inicio realiza una de estas acciones:

• Instala un programa o una característica
• Descarga los datos de caché
• Descarga información del sitio web

Solución 3: Revisión de los impactos y requisitos del servicio

Revise la sección Impactos y requisitos del servicio para saber qué esperar y cómo puede evitar o mitigar los retrasos de inicio.

Problema 4: Azure no reinicia el sistema operativo host o invitado después de una actualización

En raras ocasiones, Es posible que Azure no reinicie el sistema operativo host o invitado después de una actualización. En este escenario, probablemente verá un mensaje "Esperando host" en el portal que no cambia después de 30 minutos o más.

Solución 4a: Corrección del código de inicio

Si puede usar el Protocolo de Escritorio remoto (RDP) para conectarse a la instancia de rol, es posible que se produzca un error en el código de inicio que pueda corregir. Para obtener más información sobre cómo corregir el código de inicio, vea Solución 1: Conectarse a la máquina virtual y depurar el error de inicio o código de forma remota.

Solución 4b: Eliminación de la implementación

Si no puede usar RDP para conectarse a la instancia de rol, probablemente la única manera de recuperar la instancia es eliminar la implementación.

Problema 5: Una o varias instancias de rol no están disponibles durante la actualización del sistema operativo

Si alguna instancia de rol no está disponible durante la actualización del sistema operativo, esto puede provocar una reducción de la capacidad del servicio. Por ejemplo, supongamos que tiene dos instancias de un rol web y que ambas instancias suelen ejecutarse con un uso de CPU del 75 %. Si se reinicia una instancia durante la actualización, el tráfico se redirige a la instancia restante. Esa instancia no puede controlar la carga adicional. Esto provoca una reducción en la disponibilidad del servicio.

Solución 5: Mantener suficiente capacidad sobrante en el servicio

Asegúrese de que el servicio tiene suficiente capacidad sobrante para absorber un determinado porcentaje de instancias de rol que no están disponibles. Para calcular la cantidad de capacidad excesiva que tiene que poner a disposición, divida el número uno por el número de dominios de actualización. Por ejemplo, si tiene dos dominios de actualización, necesita un 1/2 = 50 % de capacidad excesiva para controlar que un dominio de actualización deje de estar disponible. Si tiene cinco dominios de actualización, necesita 1/5 = 20 % de capacidad excesiva para controlar la pérdida de disponibilidad en uno de los cinco dominios de actualización.

Problema 6: Los clientes experimentan interrupciones o tiempos de espera porque el sitio web tarda demasiado tiempo en calentarse

¿Su sitio web tarda varios minutos en calentarse? (Por ejemplo, la preparación del sitio web podría constar de IIS estándar o ASP.NET precompilación y carga de módulos, o podría estar calentando una memoria caché u otras tareas específicas de la aplicación). En este caso, los clientes pueden experimentar una interrupción o tiempos de espera aleatorios.

Una vez que se reinicia una instancia de rol y OnStart el código finaliza su ejecución, la instancia de rol se restaura a la rotación del equilibrador de carga. A continuación, la instancia de rol comenzará a recibir solicitudes entrantes. Si el sitio web todavía se está calentando, todas esas solicitudes entrantes se pondrán en cola y agotarán el tiempo de espera. Supongamos que solo tiene dos instancias del rol web. En este caso, la instancia recibirá el IN_0 100 % de las solicitudes entrantes mientras se reinicia la IN_1 instancia para la actualización del sistema operativo invitado. Sin embargo, la IN_0 instancia todavía se está calentando. Este escenario puede provocar una interrupción completa del servicio hasta que el sitio web termine de calentarse en ambas instancias.

Solución 6: Impedir que una instancia de rol reciba solicitudes entrantes hasta que finalice la preparación

Se recomienda evitar que el código de control de eventos de la OnStart instancia de rol finalice hasta que el sitio web complete su preparación. Para implementar este proceso de evento, puede usar el código de ejemplo siguiente:

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

Más información

• Preguntas más frecuentes sobre los reinicios de instancias de rol desde las actualizaciones del sistema operativo de máquina virtual de Azure

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.