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 apagará las implementaciones en ejecución existentes y los datos se perderán permanentemente 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 en el contexto de Azure hay pequeñas diferencias entre los distintos tipos de actualización, en este documento el término "actualización" se usa de forma general en las explicaciones de 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
- Cómo se realiza una actualización
- Reversión de una actualización
- Iniciación de varias operaciones mutantes en una implementación en curso
- Distribución de roles entre dominios de actualización
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 instancias de un rol concreto | 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 Intercambiar implementaciones.
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:
En el diagrama siguiente se ilustra cómo tiene lugar la actualización si solo se actualiza un único rol:
Durante una actualización automática, el controlador de tejido de Azure evalúa periódicamente el estado del servicio en la nube para determinar cuándo es seguro introducir el siguiente UD. Esta evaluación de estado se realiza por rol y tiene en cuenta únicamente las instancias de la versión más reciente (es decir, instancias de las UD que ya se han introducido). Comprueba que, para cada rol, un número mínimo de instancias de rol, han alcanzado un estado terminal satisfactorio.
Tiempo de espera de inicio de la instancia de rol
El controlador de tejido espera 30 minutos a que cada instancia de rol llegue a 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 local | Conservado | Conservado | Destruido |
| Migración de nodos | Destruido | Destruido | Destruido |
En la lista anterior, la unidad E: representa la unidad raíz de rol y no se debe codificar de forma rígida. En su lugar, use la variable de entorno %RoleRoot% para representar la unidad.
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.
Reversión de 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 realizar una reversión en una actualización en contexto 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 Actualización o reversión de la actualización, que se puede llamar en una actualización de configuración (desencadenada al llamar a Cambiar configuración de implementación) o una actualización (desencadenada al llamar a Actualizar implementación) siempre que haya como mínimo una instancia en el servicio que aún no se haya actualizado a la nueva versión.
El elemento bloqueado y el elemento RollbackAllowed, que se devuelven como parte del cuerpo de respuesta de las operaciones Obtener implementación y Obtener propiedades de servicio en la nube:
- El elemento bloqueado permite detectar cuándo se puede invocar una operación de mutación en una implementación determinada.
- El elemento RollbackAllowed permite detectar cuándo la operación de Actualización o reversión de la actualización puede llamarse 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á establecido 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 vertical, es posible que no tenga una cuota de proceso 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 la reversión de una actualización podría resultar útil es si se usa la operación Actualizar implementación en el modo manual para controlar la velocidad a la que se realiza una actualización local importante en el servicio hospedado de Azure.
Durante la ejecución de la actualización, se llama a Actualizar implementación en modo manual y se comienzan a recorrer 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 Revertir actualización o actualizar 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 quiera iniciar varias operaciones simultáneas de mutació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 desbloquear la implementación revirtiendo la actualización o aplicando una nueva actualización encima de la que tiene los errores.
Una vez que el controlador de tejido de Azure recibe la solicitud inicial para actualizar el servicio, puede iniciar las operaciones de mutación siguientes. 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 la marca Locked para determinar si puede invocar una operación de mutación en una implementación determinada.
Para llamar a la versión de estos métodos que devuelve la marca Locked, 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 uniformemente en un número determinado de dominios de actualización, que pueden configurarse como parte del archivo de definición (.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.
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