Compartir vía

Actualización de un servicio de Azure Cloud Services (clásico)

Importante

Cloud Services (clásico) ahora está en desuso para todos los clientes a partir del 1 de septiembre de 2024. Microsoft detendrá y cerrará todas las implementaciones en curso y los datos se perderán de forma permanente a partir de octubre de 2024. Las nuevas implementaciones deben utilizar el nuevo modelo de implementación basado en Azure Resource Manager Azure Cloud Services (soporte extendido) .

El proceso para actualizar un servicio en la nube, incluidos sus roles y el sistema operativo invitado, tiene tres pasos. En primer lugar, se deben cargar los archivos binarios y archivos de configuración para el nuevo servicio en la nube, o la versión del sistema operativo. A continuación, Azure reserva recursos informáticos y de red para el servicio en la nube según los requisitos de la nueva versión de dicho servicio. Por último, Azure lleva a cabo una actualización gradual para actualizar de forma incremental el inquilino a la nueva versión o sistema operativo invitado, conservando su disponibilidad. En este artículo se tratan los detalles de este último paso: la actualización gradual.

Actualización de un servicio de Azure

Azure organiza las instancias de rol en agrupaciones lógicas denominadas dominios de actualización (UD). Los dominios de actualización (UD) son conjuntos lógicos de instancias de rol que se actualizan como un grupo. Azure actualiza un servicio en la nube con los UD de uno en uno, lo que permite a las instancias de otros UD continuar atendiendo el tráfico.

El número predeterminado de dominios de actualización es 5. Puede especificar un número diferente de dominios de actualización incluyendo el atributo upgradeDomainCount en el archivo de definición de servicio (.csdef). Para más información sobre el atributo upgradeDomainCount, consulte Esquema de definición de Azure Cloud Services (archivo .csdef).

Al realizar una actualización local de uno o varios roles en el servicio, Azure actualiza los conjuntos de instancias de rol según el dominio de actualización al que pertenecen. Azure actualiza todas las instancias de un dominio de actualización dado (deteniéndolas, actualizándolas, conectándolas de nuevo), y luego pasa al dominio siguiente. Al detener solo las instancias que se ejecutan en el dominio de actualización en ese moment, Azure se asegura de que una actualización se realiza con el menor impacto posible en el servicio que está en ejecución. Para obtener más información, consulte Cómo se realiza una actualización más adelante en este artículo.

Nota:

Aunque los términos actualización y mejora tienen significados ligeramente diferentes en el contexto de Azure, en este documento se pueden usar indistintamente para los procesos y las descripciones de las características.

El servicio tiene que definir al menos dos instancias de un rol para que ese rol se actualice localmente sin tiempo de inactividad. Si consta de una única instancia de un rol, el servicio no está disponible hasta que finalice la actualización local.

En este artículo se describe la siguiente información sobre las actualizaciones de Azure:

Cambios de servicio permitidos durante una actualización

La siguiente tabla muestra los cambios permitidos en un servicio durante una actualización:

Cambios permitidos en el hospedaje, servicios y roles Actualización local Por etapas (intercambio de VIP) Eliminación y reimplementación
Versión del sistema operativo Sí Sí Sí
Nivel de confianza de .NET Sí Sí Sí
Tamaño de la máquina virtual1 Sí2 Sí Sí
Configuración de almacenamiento local Solo aumentar2 Sí Sí
Agregar o quitar roles en un servicio Sí Sí Sí
Número de veces que un rol específico ha ocurrido Sí Sí Sí
Número o tipo de puntos de conexión de un servicio Sí2 No Sí
Nombres y valores de configuración Sí Sí Sí
Valores (pero no nombres) de configuración Sí Sí Sí
Incorporación de nuevos certificados Sí Sí Sí
Cambio de certificados existentes Sí Sí Sí
Implementación de nuevo código Sí Sí Sí

1 Cambio de tamaño limitado al subconjunto de tamaños disponibles para el servicio en la nube.

2 Requiere Azure SDK 1.5 o versiones posteriores.

Advertencia

Cambiar el tamaño de la máquina virtual destruirá los datos locales.

Los elementos siguientes no se admiten durante una actualización:

  • Cambio del nombre de un rol. Quitar y, a continuación, agregar el rol con el nuevo nombre.
  • Cambio del número de dominios de actualización.
  • Disminución del tamaño de los recursos locales.

Si realiza otras actualizaciones de la definición del servicio, como reducir el tamaño del recurso local, en su lugar debe realizar una actualización de intercambio de VIP. Para obtener más información, consulte Implementación de Swap.

Cómo se realiza una actualización

Puede decidir si desea actualizar todos los roles en el servicio o un único rol. En cualquier caso, todas las instancias de cada rol que se está actualizando y que pertenecen al primer dominio de actualización se detienen, se actualizan y se vuelven a conectar. Una vez que se vuelvan a conectar, las instancias en el segundo dominio de actualización se detienen, se actualizan y se vuelven a conectar. Un servicio en la nube puede tener como mucho una actualización activa a la vez. La actualización se realiza siempre con la versión más reciente del servicio en la nube.

En el siguiente diagrama se ilustra cómo funciona la actualización si se actualizan todos los roles en el servicio:

Actualización del servicio

En el diagrama siguiente se ilustra cómo tiene lugar la actualización si solo se actualiza un único rol:

Actualización de roles

Durante una actualización automática, el Azure Fabric Controller evalúa periódicamente la salud del servicio en la nube para determinar cuándo es seguro avanzar al siguiente UD. Esta evaluación de salud se realiza sobre una base por rol y tiene en cuenta únicamente las instancias de la versión más reciente (es decir, instancias de las UDs que ya se han ejecutado). Comprueba que, para cada rol, un número mínimo de instancias de rol han alcanzado un estado satisfactorio terminal.

Tiempo de espera al iniciar la instancia de rol

El Fabric Controller espera 30 minutos para que cada instancia de rol alcance un estado Iniciado. Si ha transcurrido la duración del tiempo de espera, Fabric Controller seguirá avanzando hasta la siguiente instancia de rol.

Impacto en los datos de la unidad durante las actualizaciones de un servicio en la nube

Al actualizar un servicio de una sola instancia a varias instancias, Azure desconecta los servicios mientras se realiza la actualización. La disponibilidad de servicio garantizada por el contrato de nivel de servicio solo se aplica a los servicios que se implementan con más de una instancia. En la lista siguiente se describe cómo afecta a los datos de cada unidad cada escenario de actualización de servicio de Azure:

Escenario Unidad C Unidad D Unidad E
Reinicio de máquina virtual (VM) Conservado Conservado Conservado
Reinicio del Portal Conservado Conservado Destruido
Restablecimiento de la imagen inicial del portal Conservado Destruido Destruido
Actualización de In-Place Conservado Conservado Destruido
Migración de nodos Destruido Destruido Destruido

En la lista anterior, la unidad E: representa la unidad raíz del rol y no se debe configurar de forma fija. En su lugar, para representar la unidad, use la variable de entorno %RoleRoot%.

Para minimizar el tiempo de inactividad al actualizar un servicio de instancia única, implemente un nuevo servicio de varias instancias en el servidor de ensayo y realice un intercambio de VIP.

Deshacer una actualización

Azure proporciona flexibilidad en la administración de servicios durante una actualización y le permite iniciar más operaciones en un servicio, después de que el controlador de tejido de Azure acepte la solicitud de actualización inicial. Solo se podrá realizar una reversión cuando una actualización (un cambio de configuración) se encuentre en estado en curso en la implementación. Se considera que una actualización está en curso siempre que haya por lo menos una instancia del servicio que todavía no se haya actualizado a la nueva versión. Para probar si se permite una reversión, compruebe que el valor de la marca RollbackAllowed esté establecido en true. Las operaciones Obtener implementación y Obtener propiedades del servicio en la nube devuelven la marca RollbackAllowed como referencia.

Nota:

Solo tiene sentido hacer una reversión en una actualización in situ porque las actualizaciones del intercambio de VIP implican reemplazar una instancia en ejecución completa del servicio por otra.

La reversión de una actualización en curso tiene los efectos siguientes en la implementación:

  • Cualquier instancia de rol que aún no se haya actualizado a la nueva versión no se actualiza, porque esas instancias ya ejecutan la versión de destino del servicio.
  • Las instancias de rol que ya se hayan actualizado a la nueva versión del archivo de paquete de servicio (*.cspkg) o del archivo de configuración (*.cscfg) (o los dos), se revierten a la versión previa a la actualización de estos archivos.

Las siguientes características proporcionan esta funcionalidad:

  • La operación Reversión de actualización o mejora, que se puede realizar en una actualización de configuración (desencadenada al llamar a Cambiar configuración de implementación) o una mejora (desencadenada al llamar a Actualizar implementación) siempre que haya al menos una instancia en el servicio que aún no se haya actualizado a la nueva versión.

  • El elemento Locked y el elemento RollbackAllowed, que se devuelven como parte del cuerpo de respuesta de las operaciones Obtener despliegue y Obtener propiedades de servicio en la nube:

    1. El elemento bloqueado permite detectar cuándo se puede invocar una operación de mutación en una implementación determinada.
    2. El elemento RollbackAllowed permite detectar cuándo se puede llamar a la operación de Reversión de actualización o mejora en una implementación determinada.

    Para realizar una reversión, no es necesario comprobar los dos elementos Locked y RollbackAllowed. Es suficiente con confirmar que RollbackAllowed está configurado en true. Estos elementos solo se devuelven si estos métodos se invocan usando el encabezado de solicitud establecido en "x-ms-version: 2011-10-01" o una versión posterior. Para más información sobre los encabezados de control de versiones, vea el control de versiones del modelo de implementación clásica.

Hay algunas situaciones en las que no se admite la reversión de una actualización, como las siguientes:

  • Reducción de recursos locales: si la actualización aumenta los recursos locales para un rol, la plataforma Azure no permite la reversión.
  • Limitaciones de cuota: si la actualización fue una operación de reducción de escala, es posible que no tenga una cuota de computación suficiente para completar la operación de reversión. Cada suscripción de Azure tiene una cuota asociada. La cuota especifica el número máximo de núcleos que pueden consumir todos los servicios hospedados que pertenecen a esa suscripción. Si la reversión de una determinada actualización hace que la suscripción supere la cuota asignada, no se habilitará esa reversión.
  • Condición de carrera: si se completa la actualización inicial, no es posible una reversión.

Un ejemplo de cuando el retroceso de una actualización podría resultar útil es si se utiliza la operación de Actualización de Implementación en modo manual para controlar la velocidad a la que se realiza una importante actualización in situ en el servicio hospedado de Azure.

Durante la implementación de la actualización, se llama a Despliegue de Actualización en modo manual y se comienza a avanzar a través de los dominios de actualización. Si en algún momento, a medida que supervisa la actualización, observa que algunas instancias de rol en los primeros dominios de actualización no responden, puede llamar a la operación Rollback Update Or Upgrade en la implementación. Esta operación deja intactas las instancias que permanecen sin actualizar y revierte las instancias actualizadas al paquete de servicio y la configuración anteriores.

Iniciación de varias operaciones mutantes en una implementación en curso

En algunos casos, es posible que desee iniciar múltiples operaciones simultáneas de modificación en una implementación en curso. Por ejemplo, puede realizar una actualización del servicio y, mientras la actualización se distribuye por el servicio, quiere realizar algún cambio, por ejemplo, para revertir la actualización, aplicar otra actualización o incluso eliminar la implementación. Un caso en el que se podría producir este escenario es si una actualización de servicio contiene código con errores que hace que una instancia de rol actualizada se bloquee repetidamente. En este caso, el controlador de tejido de Azure no puede progresar en la aplicación de esa actualización, ya que el número de instancias en el dominio actualizado que están en buen estado es insuficiente. Este estado se denomina implementación bloqueada. Puede desatascar la implementación revirtiendo la actualización o aplicando una nueva actualización sobre la que falla.

Una vez que el Controlador de Fabric de Azure recibe la solicitud inicial para actualizar o mejorar el servicio, puede iniciar las siguientes operaciones de modificación. Es decir, no es necesario esperar a que la operación inicial se complete antes de iniciar otra operación de mutación.

Iniciar una segunda operación de actualización mientras la primera está en curso funciona de una forma similar a la operación de reversión. Si la segunda actualización está en modo automático, el primer dominio de actualización se actualiza inmediatamente, lo que podría ocasionar que las instancias de varios dominios de actualización estén sin conexión al mismo tiempo.

Las operaciones de mutación son las siguientes: Cambiar configuración de implementación, Actualizar implementación, Actualizar estado de la implementación, Eliminar implementación y Actualización o reversión de la actualización.

Dos operaciones, Obtener implementación y Obtener propiedades del servicio en la nube, devuelven la marca Locked. Puede examinar el indicador de bloqueo para determinar si puede invocar una operación mutante en una implementación determinada.

Para llamar a la versión de estos métodos que devuelve la bandera de bloqueo, debe establecer el encabezado de solicitud en "x-ms-version: 2011-10-01" o una versión posterior. Para más información sobre los encabezados de control de versiones, vea el control de versiones del modelo de implementación clásica.

Distribución de roles entre dominios de actualización

Azure distribuye las instancias de un rol de manera uniforme en un número determinado de dominios de actualización, los cuales pueden configurarse como parte del archivo de definición del servicio (.csdef). El número máximo de dominios de actualización es 20 y el número predeterminado 5. Para obtener más información sobre cómo modificar el archivo de definición de servicio, consulte Esquema de definición del servicio de Azure (archivo .csdef).

Por ejemplo, si el rol tiene diez instancias, de manera predeterminada cada dominio de actualización contiene dos instancias. Si su rol tiene 14 instancias, entonces cuatro de los dominios de actualización contienen tres instancias y un quinto dominio contiene dos.

Los dominios de actualización se identifican con un índice basado en cero: el primer dominio de actualización tiene un identificador de 0 y el segundo un identificador de 1 y así sucesivamente.

En el siguiente diagrama se ilustra cómo se distribuyen los dos roles que contiene un servicio, cuando el servicio define dos dominios de actualización. El servicio está ejecutando ocho instancias del rol web y nueve instancias del rol de trabajo.

Distribución de dominios de actualización

Nota:

Tenga en cuenta que Azure controla cómo se asignan las instancias en los dominios de actualización. No es posible especificar las instancias que se asignan a un dominio determinado.

Pasos siguientes

Administración de Cloud Services
Supervisión de Cloud Services
Configuración de Cloud Services