Présentation de la mise à jour d'un service Windows Azure

Le tableau suivant contient les modifications autorisées pour un service pendant une mise à jour :

Modifications admises pour l'hébergement, les services et les rôles	Mise à jour sur place	Intermédiaire (échange d'adresses IP virtuelles)	Suppression et redéploiement
Version du système d'exploitation	Oui	Oui	Oui
Niveau de confiance .NET	Oui	Oui	Oui
Taille de l'ordinateur virtuel	Oui Avertissement La modification de la taille de l'ordinateur virtuel détruit les données locales. Remarque Requiert Windows Azure SDK 1.5 ou une version supérieure.	Oui	Oui
Paramètres de stockage local	Oui Augmentation uniquement. Remarque Requiert Windows Azure SDK 1.5 ou une version supérieure.	Oui	Oui
Ajout ou suppression de rôles dans un service	Oui	Oui	Oui
Nombre d'instances d'un rôle particulier	Oui	Oui	Oui
Nombre ou type de points de terminaison pour un service	Oui Remarque Requiert Windows Azure SDK 1.5 ou une version supérieure. Important La disponibilité peut disparaître temporairement lors de la mise à jour des points de terminaison.	Non	Oui
Noms et valeurs des paramètres de configuration	Oui	Oui	Oui
Valeurs (sans les noms) des paramètres de configuration	Oui	Oui	Oui
Ajout de nouveaux certificats	Oui	Oui	Oui
Modification des certificats existants	Oui	Oui	Oui
Déploiement de nouveau code	Oui	Oui	Oui

Les éléments suivants ne sont pas pris en charge pendant une mise à jour :

• Changement du nom d'un rôle. Supprimez le rôle et ajoutez-le avec son nouveau nom.
  
  
• Modification du nombre de domaines de mise à niveau.
  
  
• Réduction de la taille des ressources locales.
  
  

Si vous effectuez d'autres mises à jour de votre définition de service, par exemple si vous réduisez la taille des ressources locales, vous devez effectuer à la place une mise à jour d'échange d'adresses IP virtuelles. Pour plus d'informations, consultez la rubrique Déploiement d'une mise à niveau de service dans un environnement de production en échangeant les adresses IP virtuelles dans Windows Azure.

Windows Azure permet de gérer avec souplesse les services pendant une mise à jour en vous permettant d'initier des opérations supplémentaires sur un service lorsque la demande de mise à jour initiale a été acceptée par le contrôleur de structure Windows Azure. Une restauration peut être effectuée uniquement lorsqu'une mise à jour (modification de configuration) est en cours sur le déploiement. Une mise à jour ou une mise à niveau est considérée comme étant en cours si au moins une instance du service n'a pas encore été mise à jour avec la nouvelle version. Pour tester si la restauration est autorisée, vérifiez si la valeur de l'indicateur RollbackAllowed retourné par les opérations Get Deployment et Get Hosted Service Properties est défini sur true.

Remarque

Il est opportun d'appeler une restauration sur une mise à jour ou une mise à niveau sur place uniquement depuis que les mises à niveau d'échange d'adresses virtuelles comprennent le remplacement d'une instance en cours complète de votre service par une autre. Pour plus d'informations sur l'échange d'adresses IP virtuelles, consultez Déploiement d'une mise à niveau de service dans un environnement de production en échangeant les adresses IP virtuelles dans Windows Azure.

La restauration d'une mise à jour en cours a les effets suivants sur le déploiement :

• Les instances de rôle qui n'avaient pas encore été mises à jour ou à niveau vers la nouvelle version ne sont pas mises à jour ou à niveau, étant donné que ces instances exécutent déjà la version cible du service.
  
  
• Les instances de rôle qui avaient déjà été mises à jour ou à niveau vers la nouvelle version des fichiers du package de service (*.cspkg) et/ou de configuration du service (*.cscfg) sont restaurées avec la version de pré-mise à niveau de ces fichiers.
  
  

Cette fonctionnalité est fournie par les éléments suivants :

• L'opération Rollback Update Or Upgrade, qui peut être appelée sur une mise à jour de configuration (déclenchée en appelant Change Deployment Configuration) ou sur une mise à niveau (déclenchée en appelant Upgrade Deployment) tant qu'il existe au moins une instance du service qui n'a pas encore été mise à jour vers la nouvelle version.
  
  
• L'élément Locked et l'élément RollbackAllowed, qui sont retournés dans les résultats des opérations Get Deployment et Get Hosted Service Properties :
  
  
  1. L'élément Locked vous permet de détecter le moment où une opération de mutation peut être appelée sur un déploiement donné.
     
     
  2. L'élément RollbackAllowed vous permet de détecter le moment où l'opération Rollback Update Or Upgrade peut être appelée sur un déploiement donné.
     
     
  Pour effectuer une restauration, il n'est pas nécessaire de vérifier les éléments Locked et RollbackAllowed. Il suffit de vérifier que RollbackAllowed est défini sur true. Ces éléments ne sont retournés que si ces méthodes sont appelées avec l'en-tête de requête défini sur la version suivante ou une version supérieure : "x-ms-version: 2011-10-01”. Pour plus d'informations sur les en-têtes de suivi de version, consultez la rubrique Service Management Versioning.
  
  

Dans certaines situations, la restauration d'une mise à jour ou d'une mise à niveau n'est pas prises en charges. Les conditions sont les suivantes :

• Réduction des ressources locales : si la mise à jour augmente les resources locales pour un rôle, la plateforme Windows Azure n'autorise pas la restauration. Pour plus d'informations sur la configuration des ressources locales pour un rôle, consultez la rubrique Comment configurer les ressources de stockage local.
  
  
• Limitations des quotas : si la mise à jour a été une opération d'évolution vers le bas, vos quotas de calcul ne suffisent peut-être plus pour effectuer l'opération de restauration. Chaque abonnement Windows Azure a un quota associé qui identifie le nombre maximal de cœurs qui peut être consommé par tous les services hébergés appartenant à cet abonnement. Si la restauration d'une mise à jour donnée amène votre abonnement à dépasser les quotas, cette restauration n'est pas autorisée.
  
  
• Condition de concurrence : si la mise à jour initiale est terminée, la restauration n'est pas possible.
  
  

Dans certains cas, la restauration d'une mise à jour peut être très utile, par exemple si vous utilisez l'opération Upgrade Deployment en mode manuel pour contrôler la vitesse à laquelle une mise à niveau majeure sur place de votre service hébergé Windows Azure est annulée.

Pendant le déploiement de la mise à niveau, vous appelez Upgrade Deployment en mode manuel et commencez à traiter les domaines de mise à niveau. Si lorsque vous surveillez la mise à niveau, vous constatez à un certain stade que certaines instances de rôle appartenant aux premiers domaines de mise à niveau que vous avez examinés perdent leur réactivité, vous pouvez appeler l'opération Rollback Update Or Upgrade sur le déploiement, ce qui gardera intactes les instances qui n'avaient pas encore été mises à niveau er restaurera les instances qui avaient été mises à niveau vers le package et la configuration précédents.

Dans certains cas, il peut être souhaitable d'initialiser plusieurs opérations de mutation simultanées sur un déploiement permanent. Par exemple, vous pouvez effectuer une mise à jour de service et vouloir effectuer une modification alors que cette mise à jour est déployée dans votre service, par exemple annuler la mise à jour, appliquer une mise à jour différente ou même supprimer l'ensemble du déploiement. Par exemple, cela peut être nécessaire si une mise à niveau de service contient du code bogué qui provoque le blocage répété d'une instance de rôle mise à jour. Dans ce cas, le contrôleur de structure Windows Azure ne pourra pas progresser dans l'application de cette mise à niveau, car un nombre insuffisant d'instances dans le domaine mis à niveau n'affecte pas l'intégrité. Cet état est désigné comme déploiement bloqué. Vous pouvez débloquer le déploiement en annulant la mise à jour ou en appliquant une nouvelle mise à jour sur la mise à jour qui a échoué.

Lorsque la demande initiale de mise à jour ou de mise à niveau du service a été reçue par le contrôleur de structure Windows Azure, les opérations de mutation suivantes peuvent être appelées. En d'autres termes, il n'est pas nécessaire d'attendre la fin de l'opération initiale pour appeler une autre opération de mutation.

L'initialisation d'une seconde opération de mise à jour alors que la première mise à jour est en cours équivaut à une opération d'annulation. Si la seconde mise à jour est effectuée en mode automatique, le premier domaine de mise à niveau sera mis à niveau automatiquement, ce qui amènera les instances issues de différents domaines de mise à niveau à être hors ligne au même moment.

Les opérations de mutation sont les suivantes : Change Deployment Configuration, Upgrade Deployment, Update Deployment Status, Delete Deployment et Rollback Update Or Upgrade.

Deux opérations, Get Deployment et Get Hosted Service Properties, retournent l'indicateur Locked, qui peut être examiné pour déterminer si une opération de mutation peut être appelée sur un déploiement donné.

Pour appeler la version de ces méthodes qui retourne l'indicateur Locked, vous devez définir l'en-tête de requête sur la version suivante ou une version supérieure : "x-ms-version: 2011-10-01”. Pour plus d'informations sur les en-têtes de suivi de version, consultez la rubrique Service Management Versioning.

Windows Azure répartit les instances d'un rôle uniformément sur un nombre défini de domaines de mise à niveau, ce qui peut être configuré dans le fichier de définition de service (.csdef). Le nombre maximal de domaines de mise à niveau est 20 et le nombre par défaut est 5. Pour plus d'informations sur la modification du fichier de définition de service, consultez la rubrique Schéma de définition de service Windows Azure.

Par exemple, si votre rôle a dix instances, par défaut, chaque domaine de mise à niveau contient deux instances. Si votre rôle a quatorze instances, quatre des domaines de mise à niveau contiennent trois instances et le cinquième domaine en contient deux.

Les domaines de mise à niveau sont identifiés avec un index de base zéro : le premier domaine de mise à niveau a un ID égal à 0, le deuxième domaine de mise à niveau a un ID égal à 1, et ainsi de suite.

Le diagramme suivant illustre comment deux rôles qui comprennent un service sont distribués lorsque le service définit deux domaines de mise à niveau. Le service exécute huit instances du rôle Web et neuf instances du rôle de travail.

Remarque
Notez que Windows Azure contrôle la façon dont les instances sont allouées parmi les domaines de mise à niveau. Il n'est pas possible de spécifier les instances qui sont allouées à un domaine.

Vous pouvez choisir si vous souhaitez mettre à jour tous les rôles de votre service ou un seul rôle. Dans l'un et l'autre cas, toutes les instances de chaque rôle mis à niveau et qui appartiennent au premier domaine de mise à niveau sont arrêtées, mises à niveau et remises en ligne. Une fois qu'elles sont en ligne, les instances dans le deuxième domaine de mise à niveau sont arrêtées, mises à niveau et remises en ligne.

Le diagramme suivant illustre comment se passe la mise à niveau lorsque vous mettez à niveau tous les rôles dans le service :

Le diagramme suivant illustre comment la mise à jour est effectuée si vous mettez à niveau un seul rôle :