Exportar (0) Imprimir
Expandir todo

Actualizar un servicio de Azure

Actualizado: mayo de 2014

Azure organiza las instancias de rol en agrupaciones lógicas denominadas dominios de actualización. 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 del servicio (.csdef). Para obtener más información acerca del atributo upgradeDomainCount, vea Esquema WebRole o Esquema WorkerRole.

Al realizar una actualización en contexto de uno o más roles del servicio, Azure actualiza los conjuntos de instancias de rol de acuerdo con el dominio de actualización al que pertenecen. Azure actualiza todas las instancias de un dominio de actualización determinado (deteniéndolas, actualizándolas, poniéndolas de nuevo en línea, etc.) y, a continuación, se desplaza al dominio siguiente. Al detener solo las instancias que se ejecutan en el dominio de actualización actual, Azure garantiza que las actualizaciones tienen el menor impacto posible en el servicio que se está ejecutando. Para obtener más información, vea How the update proceeds más adelante en este artículo.

noteNota
Aunque los términos actualizar y mejorar tienen un significado ligeramente diferente en el contexto de Azure, se pueden utilizar indistintamente para los procesos y las descripciones de las características en este documento.

El servicio debe definir al menos dos instancias de un rol para que dicho rol se actualice en contexto sin tiempo de inactividad. Si el servicio consta de una sola instancia de un rol, el servicio no estará disponible hasta que la actualización en contexto haya finalizado.

Este tema contiene la información siguiente sobre las actualizaciones de Azure:

En la tabla siguiente se muestran los cambios permitidos en un servicio durante una actualización:

 

Cambios permitidos en el hospedaje, los servicios y los roles Actualización en contexto Por etapas (intercambio de VIP) Eliminación y reimplementación

Versión del sistema operativo

Nivel de confianza de .NET

Tamaño de la máquina virtual

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

noteNota
Requiere Azure SDK 1.5 o versiones posteriores.

Configuración de almacenamiento local

Solo aumentar.

noteNota
Requiere Azure SDK 1.5 o versiones posteriores.

Agregar o quitar roles en un servicio

Número de instancias de un rol determinado

Número o tipo de extremos para un servicio

noteNota
Requiere Azure SDK 1.5 o versiones posteriores.

ImportantImportante
Es posible que la disponibilidad se pierda temporalmente mientras se actualizan los extremos.

No

Nombres y valores de los parámetros de configuración

Valores (pero no nombres) de los parámetros de configuración

Agregar nuevos certificados

Cambiar certificados existentes

Implementar nuevo código

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

  • Cambiar el nombre de un rol. Quitar y volver a agregar el rol con el nuevo nombre.

  • Cambiar el recuento de dominios de actualización.

  • Reducir el tamaño de los recursos locales.

Si piensa realizar otras actualizaciones en la definición del servicio, como reducir el tamaño del recurso local, deberá llevar a cabo en su lugar una actualización de intercambio de VIP. Para obtener más información, vea Administrar las actualizaciones del SO invitado de Azure.

Azure proporciona flexibilidad en la administración de servicios durante una actualización, ya que le permitirá iniciar operaciones adicionales en un servicio una vez que la solicitud inicial de actualización sea aceptada por el controlador de tejido de Azure. 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. Una actualización se considera que está en curso cuando hay al menos una instancia del servicio que aún no se ha actualizado a la nueva versión. Para averiguar si se permite una reversión, compruebe que el valor de la marca RollbackAllowed, devuelto por las operaciones Obtener implementación y Propiedades Get del servicio en la nube, esté establecido en true.

noteNota
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 sobre la implementación:

  • Las instancias de rol que aún no se hayan actualizado a la nueva versión no lo harán, debido a que dichas instancias ya están ejecutando la versión de destino del servicio.

  • Las instancias de rol que ya se hayan actualizado a la nueva versión del archivo del paquete de servicio (*.cspkg) o del archivo de configuración del servicio (*.cscfg) (o a ambos archivos) se revertirán a la versión previa a la actualización de estos archivos.

Esta funcionalidad la proporcionan las características siguientes:

  • La operación Revertir actualización o actualizar, a la que se puede llamar en una actualización de configuración (desencadenada al llamar a Cambiar configuración de implementación) o en una actualización (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.

  • Los elementos Locked y RollbackAllowed, que se devuelven como parte del cuerpo de respuesta de las operaciones Obtener implementación y Propiedades Get del servicio en la nube:

    1. El elemento Locked permite detectar cuándo se puede invocar a una operación que muta en una implementación determinada.

    2. El elemento RollbackAllowed permite detectar cuándo se puede llamar a la operación Revertir actualización o actualizar en una implementación determinada.

    Para poder realizar una reversión, no es necesario comprobar ambos 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 utilizando el encabezado de solicitud establecido en “x-ms-version: 2011-10-01” o una versión posterior. Para obtener más información acerca de los encabezados de control de versiones, vea Control de versiones de la administración del servicio.

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

  • Reducción de recursos locales: si la actualización aumenta los recursos locales de un rol, la plataforma Azure no permite la reversión. Para obtener más información sobre cómo configurar los recursos locales de un rol, vea Configurar los recursos de almacenamiento local.

  • Limitaciones de cuota: si la actualización fue una operación de reducción, es posible que ya no tenga cuota de proceso suficiente para completar la operación de reversión. Cada suscripción de Windows Azure tiene una cuota asociada que especifica el número máximo de núcleos que pueden utilizar todos los servicios hospedados que pertenecen a dicha suscripción. Si la reversión de una actualización determinada puede dar como resultado que su suscripción supere la cuota asignada, la reversión no se habilitará.

  • Condición de carrera: si la actualización inicial se ha completado, la reversión no es posible.

Un ejemplo de cuándo la reversión de una actualización puede ser útil es cuando se utiliza la operación Actualizar implementación en modo manual para controlar la velocidad con la que se implementa una actualización en contexto importante del servicio hospedado de Azure.

Durante la implementació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 alguna instancia de rol de los primeros dominios de actualización examinados ha dejado de responder, puede llamar a la operación Revertir actualización o actualizar en la implementación, que conservará intactas las instancias que aún no se hayan actualizado y revertirá aquellas que se hayan actualizado al paquete de servicio y a la configuración anteriores.

En algunos casos, es posible que desee iniciar varias operaciones simultáneas de mutación en una implementación en curso. Por ejemplo, puede llevar a cabo una actualización de servicio y, mientras esta se implementa en el servicio, realizar ciertos cambios, por ejemplo revertir la actualización, aplicar otra actualización o incluso eliminar la implementación. Un caso en el que esto podría ser necesario es cuando una actualización de servicio contiene código con errores que hace que una instancia de rol actualizada se bloquee continuamente. En este caso, el controlador de tejido de Azure no podrá aplicar la actualización, ya que hay un número insuficiente de instancias correctas en el dominio de actualización. Este estado se denomina implementación bloqueada. Para desbloquear la implementación, revierta la actualización o aplique una nueva actualización encima de la errónea.

Una vez que el controlador de tejido de Azure ha recibido la solicitud inicial para actualizar el servicio, ya puede iniciar las subsiguientes operaciones de mutación. Es decir, no tiene que esperar a que se complete la operación inicial para iniciar otra operación de mutación.

Si se inicia una segunda operación de actualización mientras la primera actualización está en curso, el resultado será similar al conseguido con la operación de reversión. Si la segunda actualización está en modo automático, el primer dominio de actualización se actualizará inmediatamente, lo que probablemente ocasionará que instancias de varios dominios de actualización estén sin conexión en el mismo momento.

Las operaciones de mutación son las siguientes: Cambiar configuración de implementación, Actualizar implementación, Actualizar estado de implementación, Eliminar una implementación y Revertir actualización o actualizar.

Dos operaciones, Obtener implementación y Propiedades Get del servicio en la nube, devuelven la marca Locked que se puede examinar para determinar si una operación de mutación se puede invocar 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 posterior. Para obtener más información acerca de los encabezados de control de versiones, vea Control de versiones de la administración del servicio.

Azure distribuye las instancias de un rol de forma uniforme entre un número determinado de dominios de actualización, que se pueden configurar como parte del archivo de definición de servicio (.csdef). El número máximo de dominios de actualización es 20 y el predeterminado, 5. Si desea más información sobre cómo modificar el archivo de definición del servicio, consulte Esquema de definición del servicio de Azure (archivo .csdef).

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

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

En el diagrama siguiente se muestra cómo se distribuye un servicio que contiene dos roles 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 los dominios de actualización

noteNota
Observe que Azure controla la asignación de las instancias entre los dominios de actualización. No es posible especificar las instancias que se deben asignar a un dominio determinado.

Puede decidir si desea actualizar todos los roles del servicio o un único rol del servicio. En ambos casos, todas las instancias del rol que se está actualizando y que pertenecen al primer dominio de actualización se detienen, se actualizan y se ponen de nuevo en línea. Una vez que están en línea de nuevo, las instancias del segundo dominio de actualización se detienen, se actualizan y se vuelven a poner en línea.

En el diagrama siguiente se muestra cómo se realiza la actualización si se actualizan todos los roles del servicio:

Servicio de actualización

En el diagrama siguiente se muestra cómo se realiza la actualización si solo se actualiza un único rol:

Rol de actualización
noteNota
Cuando se actualiza un servicio desde una instancia única a varias instancias, el servicio se desactiva mientras se realiza la actualización debido a la manera en la que Windows Azure actualiza los servicios. El acuerdo de nivel de servicio que garantiza la disponibilidad del servicio solo se aplica a los servicios implementados con más de una instancia. En la lista siguiente se describe cómo afectan los distintos escenarios de actualización de servicios de Windows Azure a los datos de cada unidad:

Reinicio de la VM:

  • C: conservada

  • D: conservada

  • E: conservada

Reinicio del portal:

  • C: conservada

  • D: conservada

  • E: destruida

Restablecimiento de imagen inicial del portal:

  • C: conservada

  • D: destruida

  • E: destruida

Actualización en contexto:

  • C: conservada

  • D: conservada

  • E: destruida

Migración de nodo:

  • C: destruida

  • D: destruida

  • E: destruida

Observe que, en la lista anterior, la unidad E: representa a la unidad raíz del rol y no se debe codificar de forma rígida. En su lugar, utilice 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.

Mostrar:
© 2014 Microsoft