VENTES: 1-800-867-1389

Mettre à jour un service Azure

Mis à jour: mai 2014

Azure organise vos instances de rôle en regroupements logiques appelés domaines de mise à niveau. Le nombre de domaines de mise à niveau par défaut est de 5. Vous pouvez spécifier un nombre différent en incluant l'attribut upgradeDomainCount dans le fichier de définition du service (.csdef). Pour plus d'informations sur l'attribut upgradeDomainCount, consultez Schéma WebRole ou Schéma WorkerRole.

Lorsque vous effectuez une mise à jour sur place d'un ou de plusieurs rôles de votre service, Azure met à jour les ensembles d'instances de rôle selon le domaine de mise à niveau auquel ils appartiennent. Azure met à jour toutes les instances d'un domaine de mise à niveau donné – en les arrêtant, en les mettant à jour et en les remettant en ligne –, puis passe au domaine suivant. En arrêtant uniquement les instances s'exécutant dans le domaine de mise à niveau actif, Azure assure qu'une mise à jour se produit avec le moins d'impact possible sur le service en cours d'exécution. Pour plus d'informations, consultez How the update proceeds plus loin dans cet article.

noteRemarque
Bien que les termes mise à jour et mise à niveau aient une signification légèrement différentes dans le contexte Azure, ils peuvent être utilisés de façon interchangeable dans le présent document pour les processus et les descriptions des fonctionnalités.

Votre service doit définir au moins deux instances d'un rôle pour ce rôle soit mis à jour sur place sans interruption du service. Si le service ne se compose que d'une seule instance pour un rôle, votre service sera indisponible jusqu'à ce que la mise à jour sur place soit terminée.

Cette rubrique contient les informations suivantes sur les mises à jour Azure :

Le tableau suivant montre les modifications autorisées d'un service pendant une mise à jour :

 

Modifications autorisées sur l'hébergement, les services et les rôles Mise à jour sur place Intermédiaire (échange d'adresses IP virtuelles) Supprimer et redéployer

Version du système d'exploitation

Oui

Oui

Oui

Niveau de confiance .NET

Oui

Oui

Oui

Taille de la machine virtuelle

Oui

WarningAvertissement
La modification de la taille de la machine virtuelle détruira les données locales.

noteRemarque
Nécessite Azure SDK 1.5 ou versions ultérieures.

Oui

Oui

Paramètres de stockage local

Oui

Augmentation uniquement.

noteRemarque
Nécessite Azure SDK 1.5 ou versions ultérieures.

Oui

Oui

Ajouter ou supprimer les rôles d'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

noteRemarque
Nécessite Azure SDK 1.5 ou versions ultérieures.

ImportantImportant
La disponibilité peut être temporairement perdue lorsque les points de terminaison sont mis à jour.

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

Ajouter de nouveaux certificats

Oui

Oui

Oui

Modifier les certificats existants

Oui

Oui

Oui

Déployer un nouveau code

Oui

Oui

Oui

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

  • Modification du nom d'un rôle. Supprimez le rôle, puis ajoutez le rôle avec le nouveau nom.

  • Modification du nombre de domaines de mise à niveau.

  • Diminution de la taille des ressources locales.

Si vous apportez d'autres mises à jour à la définition de votre service, comme la réduction de la taille de la ressource locale, vous devez effectuer à la place une mise à jour d'échange d'adresses IP virtuelles. Pour plus d'informations, consultez Gérer les mises à niveau du système d'exploitation invité de Azure.

Azure garantit la souplesse de la gestion des services pendant une mise à jour en vous permettant de lancer des opérations supplémentaires sur un service, après acceptation de la demande de mise à jour par le contrôleur de structure Azure. Une restauration ne peut être effectuée que lorsqu'une mise à jour (modification de configuration) ou une mise à niveau est dans l'état en cours sur le déploiement. Une mise à jour ou une mise à niveau est considérée comme en cours tant qu'il y a au moins une instance du service qui n'a pas encore été mise à jour vers la nouvelle version. Pour tester si une restauration est autorisée, vérifiez que la valeur de l'indicateur RollbackAllowed, retournée par les opérations Obtenir un déploiement et Obtenir les propriétés d'un service cloud, est true.

noteRemarque
L'appel de la fonction de restauration sur une mise à jour ou mise à niveau sur place ne se justifie que parce que les échanges d'adresses virtuelles IP impliquent de remplacer une instance complète de votre service en cours d'exécution par une autre.

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

  • Toutes 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, car ces instances exécutent déjà la version cible du service.

  • Toutes les instances de rôle qui avaient déjà été mises à jour ou à niveau vers la nouvelle version du fichier du package de service (*.cspkg) ou du fichier de configuration du service (*.cscfg) (ou les deux fichiers) sont rétablies à la version antérieure à la mise à niveau de ces fichiers.

Cette fonction est assurée par les fonctionnalités suivantes :

  • L'opération Restauration de mise à jour ou de mise à niveau, qui peut être appelée sur une mise à jour de configuration (déclenchée en appelant Modifier la configuration du déploiement) ou une mise à niveau (déclenchée en appelant Mettre à niveau un déploiement) aussi longtemps qu'il subsiste 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 comme faisant partie du corps de la réponse des opérations Obtenir un déploiement et Obtenir les propriétés d'un service cloud :

    1. L'élément Locked vous permet de détecter lorsqu'une opération de mutation peut être appelée sur un déploiement donné.

    2. L'élément RollbackAllowed vous permet de détecter lorsque l'opération Restauration de mise à jour ou de mise à niveau peut être appelée sur un déploiement donné.

    Pour effectuer une restauration, vous ne devez pas activer les deux éléments Locked et RollbackAllowed. Il suffit de confirmer que RollbackAllowed a la valeur true. Ces éléments sont retournés uniquement si ces méthodes sont appelées à l'aide de l'en-tête de requête Set Server défini avec la valeur « x-ms-version : 2011-10-01 » ou version ultérieure. Pour plus d'informations sur les en-têtes du suivi de version, consultez Contrôle de version du service de gestion.

Il existe quelques situations où une restauration d'une mise à jour ou d'une mise à niveau n'est pas prise en charge. Par exemple :

  • Réduction des ressources locales. Si la mise à jour augmente les ressources locales pour un rôle dont la plateforme Azure n'autorise pas la restauration. Pour plus d'informations sur la configuration des ressources locales pour un rôle, consultez Configurer les ressources de stockage local.

  • Limitations de quota. Si la mise à jour était une opération de réduction, il se peut que vous n'ayez plus le quota de calcul suffisant pour terminer l'opération de restauration. Chaque abonnement Windows Azure possède un quota associé qui spécifie le nombre maximal de cœurs qui peuvent être consommés par tous les services hébergés qui appartiennent à cet abonnement. Si l'exécution de la restauration d'une mise à jour donnée entraîne un dépassement du quota de votre abonnement, la restauration ne sera pas activée.

  • Condition de concurrence. Si la mise à jour initiale est achevée, la restauration n'est pas possible.

Un exemple de cas où la restauration d'une mise à jour peut être utile est celui où vous utilisez l'opération Mettre à niveau un déploiement en mode manuel pour contrôler la fréquence à laquelle une mise à niveau majeure sur place de votre service hébergé Azure est déployée.

Pendant le déploiement de la mise à niveau, vous appelez Mettre à niveau un déploiement en mode manuel et commencez à parcourir les domaines de mise à niveau. Si à un certain point, pendant que vous surveillez la mise à niveau, vous notez que certaines instances de rôle des premiers domaines de mise à niveau que vous examinez commencent à ne pas répondre, vous pouvez appeler l'opération Restauration de mise à jour ou de mise à niveau sur le déploiement, laquelle ignorera les instances qui n'avaient pas encore été mises à niveau et les instances de restauration qui avaient été mises à niveau vers la configuration et le service de package précédents.

Dans certains cas, vous pouvez vouloir initialiser plusieurs opérations de mutation simultanées sur un déploiement en cours. Par exemple, vous pouvez effectuer une mise à jour de service et, tandis que cette mise à jour est déployée sur votre service, vouloir apporter certaines modifications, comme annuler la mise à jour, appliquer une autre mise à jour ou même, supprimer le déploiement. Un cas où cela peut être nécessaire est celui où une mise à niveau de service contient un code bogué qui entraîne l'arrêt répété d'une instance de rôle mise à niveau. Dans ce cas, le contrôleur de structure Azure ne parvient pas faire progresser l'application de la mise à niveau, parce qu'un nombre insuffisant d'instances du domaine mis à niveau sont saines. Cet état est connu sous le nom de déploiement bloqué. Vous pouvez débloquer le déploiement en annulant la mise à jour ou en appliquant une nouvelle mise à jour sur celle défaillante.

Une fois la demande initiale de mise à jour ou de mise à niveau reçue par le contrôleur de structure Azure, vous pouvez commencer les opérations de mutation suivantes. Autrement dit, vous ne devez pas attendre que l'opération initiale soit terminée avant de pouvoir commencer une autre opération de mutation.

Le lancement d'une deuxième opération de mise à jour pendant que la première mise à jour est en cours s'exécutera de façon semblable à l'opération de restauration. Si la deuxième mise à jour est en mode automatique, le premier domaine de mise à niveau sera mis à niveau immédiatement, ce qui conduira probablement à ce que les instances de plusieurs domaines de mise à niveau soient hors connexion au même moment.

Les opérations de mutation sont les suivantes : Modifier la configuration du déploiement, Mettre à niveau un déploiement, Mettre à jour l'état du déploiement, Supprimer un déploiement et Restauration de mise à jour ou de mise à niveau.

Deux opérations, Obtenir un déploiement et Obtenir les propriétés d'un service cloud, 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, définissez l'en-tête de demande à la valeur « x-ms-version: 2011-10-01 » ou version ultérieure. Pour plus d'informations sur les en-têtes du suivi de version, consultez Contrôle de version du service de gestion.

Azure distribue uniformément les instances d'un rôle à travers un nombre défini de domaines de mise à niveau, qui peuvent être configurés comme faisant partie du fichier de définition de service (.csdef). Le nombre maximal de domaines de mise à niveau est 20 et la valeur par défaut, 5. Pour plus d'informations sur la modification du fichier de définition de service, consultez Schéma de définition du service Azure (fichier .csdef).

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

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

Le diagramme suivant montre comment un service qui contient deux rôles se répartit 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.

Répartition des domaines de mise à niveau

noteRemarque
Notez que Azure contrôle comment les instances sont allouées entre les domaines de mise à niveau. Il est impossible de spécifier quelle instance est allouée à tel ou tel domaine.

Vous pouvez déterminer si vous voulez mettre à jour tous les rôles de votre service ou un seul rôle du service. Dans les deux cas, toutes les instances de chaque rôle qui sont mises à niveau et appartiennent au premier domaine de mise à niveau sont arrêtées, mises à niveau et remises en ligne. Puis, les instances du deuxième domaine de mise à niveau sont à leur tour arrêtées, mises à niveau et remises en ligne.

Le diagramme suivant montre comment la mise à niveau se poursuit si vous mettez à niveau tous les rôles du service :

Mettre à niveau le service

Le diagramme suivant montre comment la mise à jour se poursuit si vous mettez à niveau un seul rôle :

Mettre à niveau le rôle
noteRemarque
Lorsque vous mettez à niveau un service d'une seule instance sur plusieurs instances, votre service est réduit pendant la mise à niveau en raison de la façon dont Windows Azure met à niveau les services. Le contrat de niveau de service garantissant la disponibilité des services s'applique uniquement aux services qui sont déployés avec plusieurs instances. La liste suivante explique comment les données de chaque disque sont affectées le scénario Windows Azure de mise à niveau de service :

Redémarrage machine virtuelle :

  • C: Conservées

  • D: Conservées

  • E: Conservées

Redémarrage portail :

  • C: Conservées

  • D: Conservées

  • E: Supprimées

Réinitialisation portail :

  • C: Conservées

  • D: Supprimées

  • E: Supprimées

Mise à niveau sur place :

  • C: Conservées

  • D: Conservées

  • E: Supprimées

Migration de nœud :

  • C: Supprimées

  • D: Supprimées

  • E: Supprimées

Notez que, dans la liste ci-dessus, le lecteur E: représente le lecteur racine du rôle, et qu'il ne doit pas être codé en dur. Au lieu de cela, utilisez la variable d'environnement %RoleRoot% pour représenter le lecteur.

Pour réduire le temps d'arrêt lorsque vous mettez à niveau un service à une seule instance, déployez un nouveau service à plusieurs instances sur le serveur intermédiaire et exécutez un échange d'adresses IP virtuelles.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft