Compartir a través de

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

  • Artículo

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 sistema operativo y del agente invitado, los impactos y los requisitos del servicio, la notificación, la detección y cómo resolver problemas comunes.

Actualice las programaciones de

De forma mensual, 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 la matriz de compatibilidad del SDK y las versiones del SO invitado de Azure. Durante esta implementación, el controlador de Tejido de Azure realiza dos pasos (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 pasos 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, las distintas instancias de la implementación se actualizan varias horas de diferencia.

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

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 usando 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 una imagen 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 tiene que coordinar solo 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
  • El 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 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 apaga 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 los requisitos del servicio en la nube:

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

  • Espere que las instancias de rol se reinicien para la actualización del sistema operativo host aproximadamente una vez cada mes. Si tiene actualizaciones automáticas del sistema operativo invitado, espere que las instancias se reinicien de nuevo. Normalmente, los reinicios están separados varias horas. 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 debe cumplir las reglas que rigen las actualizaciones del sistema operativo host. En concreto, las instancias de rol deben alcanzar el Ready estado en un plazo de 30 minutos a partir de iniciar las tareas de inicio. Para obtener más información sobre esta limitación, consulte 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 de la instancia. Debido a estos eventos, las instancias de rol deben poder controlar los procedimientos siguientes:

    • Reiniciar
    • Restablecer imagen inicial
    • Recycle

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 realice la instancia de rol o para notificar a un administrador que se está cerrando una instancia.

Puede suscribirse a la fuente RSS de actualizaciones 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 varios días entre el momento en que se actualiza la fuente RSS y el servicio hospedado comienza a actualizarse.

La lista de versiones del so invitado de Azure y la lista de versiones del sistema operativo que están disponibles para su selección en Azure Portal, se actualizan normalmente una vez completada la implementación del sistema operativo invitado. No debe usar la entrada más reciente en 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:

Problemas comunes y soluciones

En las secciones siguientes se describen algunos problemas comunes que implican reinicios de instancias de rol y cómo se pueden resolver. 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, la tarea de inicio producirá un error y hará que la instancia de rol empiece a reciclarse. 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 produce un error en su segunda ejecución. El comando genera el mensaje de error "New add object missing required attributes. No se puede agregar la entrada de colección duplicada de tipo..." A continuación, la instancia de rol comienza a reciclarse.

Solución 1: Conexión a la máquina virtual y depuración del 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 de los errores y compruebe los errores de la tarea de inicio del archivo WaHostBootstrapper.log . Durante el proceso de desarrollo y pruebas típico, debe iniciar proactivamente un reinicio de las instancias de rol desde 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 exit finaliza el script mediante un código de salida que indica que se ha realizado correctamente. Para 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 ejecuta 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 la 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 ciertos cambios del Registro siguen existiendo después de que se vuelva a crear la 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 a la reimposición y la tarea de inicio no restaurará ese cambio de 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: Prueba de la reimposición de instancias de rol desde Azure Portal

Durante el proceso de desarrollo y pruebas típicos, debe iniciar proactivamente una nueva imagen de las instancias de rol desde 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 del 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 de datos de caché
  • Descarga información del sitio web

Solución 3: Revisión de los impactos y los 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 host o el sistema operativo invitado después de una actualización

En raras ocasiones, Es posible que Azure no reinicie el host o el sistema operativo 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, puede haber un error en el código de inicio que puede corregir. Para obtener más información sobre cómo corregir el código de inicio, consulte Solución 1: Conexión a la máquina virtual y depuración remota del error de inicio o código.

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 se ejecutan normalmente en un 75 por ciento de uso de CPU. 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 de la disponibilidad del servicio.

Solución 5: Mantener suficiente exceso de capacidad en el servicio

Asegúrese de que el servicio tiene suficiente capacidad suficiente para absorber un determinado porcentaje de instancias de rol que no están disponibles. Para calcular la cantidad de capacidad excesiva que tiene que hacer disponible, divida el número uno por el número de dominios de actualización. Por ejemplo, si tiene dos dominios de actualización, necesita 1/2 = 50 % de capacidad excesiva para controlar que un dominio de actualización no esté 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 puede constar de IIS estándar o ASP.NET precompilación y carga de módulos, o bien podría estar calentando una 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 reiniciada una instancia de rol y el OnStart código completa su ejecución, la instancia de rol se restaura en la rotación del equilibrador de carga. A continuación, la instancia de rol comenzará a recibir solicitudes entrantes. Si su sitio web todavía se está calentando, todas esas solicitudes entrantes se ponerán en cola y agotarán el tiempo de espera. Supongamos que solo tiene dos instancias del rol web. En este caso, la IN_0 instancia recibirá el 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 haya terminado de calentarse en ambas instancias.

Solución 6: Detener que una instancia de rol reciba solicitudes entrantes hasta que finalice el proceso de preparación

Se recomienda mantener el OnStart código de control de eventos para la instancia de rol 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

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.