Comment mettre à jour un service cloud Azure (classique)
Important
Services Cloud (classique) est désormais déconseillé pour les nouveaux clients et sera supprimé le 31 août 2024 pour tous les clients. Les nouveaux déploiements doivent utiliser le nouveau modèle de déploiement basé sur Azure Resource Manager Azure Cloud Services (support étendu) .
Le processus pour mettre à jour un service cloud, notamment ses rôles et son système d’exploitation invité, se déroule en trois étapes. Tout d’abord, les fichiers binaires et de configuration du nouveau Service Cloud et de la version de système d’exploitation doivent être téléchargés. Dans un deuxième temps, Azure réserve des ressources de calcul et réseau au Service Cloud selon les spécifications de la nouvelle version de Service Cloud. Enfin, Azure effectue une mise à niveau propagée pour effectuer une mise à jour incrémentielle du client vers la nouvelle version ou le nouveau système d’exploitation invité tout en préservant votre disponibilité. Cet article discute des détails de cette dernière étape, la mise à jour propagée.
Mettre à jour un Service Azure
Azure organise vos instances de rôle en regroupements logiques appelés domaines de mise à niveau (UD). Les domaines de mise à niveau (UD) sont des ensembles logiques d’instances de rôle qui sont mis à jour en tant que groupe. Azure met à jour un domaine de mise à niveau de Service Cloud à la fois, ce qui permet aux instances présentes sur les autres domaines de mise à niveau de maintenir le trafic.
Le nombre de domaines de mise à niveau par défaut est de 5. Vous pouvez spécifier un nombre différent de domaines de mise à niveau 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 de définition Microsoft Azure Cloud Services (fichier .csdef).
Lorsque vous effectuez la mise à jour sur place d’un ou de plusieurs rôles dans votre service, Azure met à jour les ensembles d’instances de rôle en fonction du domaine de mise à niveau auquel ils appartiennent. Azure met à jour toutes les instances dans un domaine de mise à niveau donné (les arrête, les met à jour, les remet en ligne) puis passe au domaine suivant. En arrêtant uniquement les instances en cours d’exécution dans le domaine de mise à niveau en cours, Azure garantit que l’opération aura un impact minimal sur le service en cours d’exécution. Pour plus d'informations, consultez la section Fonctionnement de la mise à niveau plus loin dans cet article.
Notes
Bien que les termes mise à jour et mise à niveau aient une signification légèrement différente dans le contexte Azure, ils peuvent être utilisés indifféremment pour les processus et les descriptions des fonctionnalités du présent document.
Votre service doit définir au moins deux instances d’un rôle pour que le rôle soit mis à jour sur place, sans interruption de service. Si le service se compose d’une seule instance d’un rôle, votre service est indisponible jusqu’à la fin de la mise à jour sur place.
Cet article décrit les informations suivantes sur les mises à jour Azure :
- Modifications de service autorisées pendant une mise à jour
- Déroulement d’une mise à niveau
- Restauration d’une mise à jour
- Lancement de plusieurs opérations de mutation sur un déploiement en cours
- Distribution des rôles entre domaines de mise à niveau
Modifications de service autorisées pendant une mise à jour
Le tableau suivant présente les modifications de service autorisées au cours d’une mise à jour :
| Modifications autorisées de l’hébergement, des services et des 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 virtuelle1 | Oui2 | Oui | Oui |
| Paramètres de stockage locaux | Augmentation uniquement2 | Oui | Oui |
| Ajouter et supprimer les 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 | Oui2 | Non | Oui |
| Noms et valeurs de paramètres de configuration | Oui | Oui | Oui |
| Valeurs (et non noms) des paramètres de configuration | Oui | Oui | Oui |
| Ajouter de nouveau certificats | Oui | Oui | Oui |
| Modifier les certificats existants | Oui | Oui | Oui |
| Déployer un nouveau code | Oui | Oui | Oui |
1 Modification de la taille limitée au sous-ensemble des tailles disponibles pour le service cloud.
2 Nécessite le kit de développement logiciel (SDK) Azure 1.5 ou versions ultérieures.
Avertissement
La modification de la taille de machine virtuelle détruira les données locales.
Les éléments suivants ne sont pas pris en charge pendant une mise à jour :
- Modification du nom d’un rôle. Supprimez, puis ajoutez le rôle avec le nouveau nom.
- Modification du nombre de domaines de mise à niveau.
- Réduction de la taille des ressources locales.
Si vous exécutez d’autres mises à jour de votre définition de service, comme la réduction de la taille d’une ressource locale, vous devez plutôt effectuer une mise à jour de l’échange d’adresses IP virtuelles. Pour plus d’informations, consultez Déploiement d’échange.
Déroulement d’une mise à niveau
Vous pouvez décider si vous souhaitez mettre à jour tous les rôles de votre service ou un seul rôle de ce service. Dans les deux cas, toutes les instances de chaque rôle mis à niveau qui appartiennent au premier domaine de mise à niveau sont arrêtées, mises à niveau et remises en ligne. Une fois de retour en ligne, les instances du deuxième domaine de mise à niveau sont arrêtées, mises à niveau et remises en ligne. Un service cloud peut avoir au plus une mise à niveau active à la fois. La mise à niveau s’effectue toujours sur la dernière version du service cloud.
Le diagramme suivant montre comment la mise à niveau se poursuit si vous mettez à niveau tous les rôles dans le service :
Le diagramme suivant montre comment la mise à jour se déroule en cas de mise à niveau d’un seul rôle :
Pendant une mise à jour automatique, le contrôleur de structure Azure évalue périodiquement l’intégrité du service cloud pour déterminer le moment opportun pour passer au domaine de mise à niveau suivant. Cette évaluation d’intégrité est effectuée par rôle et prend uniquement en compte les instances de la dernière version (c’est-à-dire les instances de domaines de mise à niveau qui fonctionnaient déjà). Elle vérifie que pour chaque rôle un nombre minimum d’instances de rôle a atteint un état terminal satisfaisant.
Délai de démarrage de l’instance de rôle
Le contrôleur de structure attend 30 minutes que chaque instance de rôle atteigne un état Démarré. Si la durée d'expiration est écoulée, le contrôleur de structure continuera à remonter jusqu’à l'instance de rôle suivante.
Impact sur les données de lecteur lors de la mise à jour des services cloud
Lorsque vous mettez à niveau un service d’une seule instance vers plusieurs instances, Azure met vos services hors service pendant l’exécution de la mise à niveau. Le contrat de niveau de service garantissant la disponibilité du service ne s’applique qu’aux services déployés avec plusieurs instances. La liste suivante décrit dans quelle mesure chaque scénario de mise à niveau de service Azure affecte les données sur chaque lecteur :
| Scénario | Lecteur C | Lecteur D | Lecteur E |
|---|---|---|---|
| Redémarrage de la machine virtuelle | Préservé | Préservé | Préservé |
| Redémarrage du portail | Préservé | Préservé | Détruit |
| Réinitialisation du portail | Préservé | Détruit | Détruit |
| Mise à niveau sur place | Préservé | Préservé | Détruit |
| Migration des nœuds | Détruit | Détruit | Détruit |
Dans la liste précédente, le lecteur E: représente le lecteur racine du rôle et ne doit pas être codé en dur. Utilisez plutôt la variable d’environnement %RoleRoot% pour représenter le lecteur.
Pour réduire les temps d’arrêt en cas de mise à niveau d’un service à instance unique, déployez un nouveau service à instances multiples sur le serveur intermédiaire et effectuez un échange d’adresses IP virtuelles.
Restauration d’une mise à jour
Azure offre une certaine souplesse dans la gestion des services pendant une mise à jour en vous permettant de lancer davantage d’opérations sur un service, une fois la demande de mise à jour initiale acceptée 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 mise à niveau est considérée comme en cours tant qu’il reste au moins une instance du service qui n’a pas été mise à jour vers la nouvelle version. Pour tester si une restauration est autorisée, vérifiez que la valeur de l’indicateur RollbackAllowed est définie sur True. Les opérations Obtenir le déploiement et Obtenir les propriétés du service cloud retournent l’indicateur RollbackAllowed pour votre référence.
Remarque
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.
Le rétablissement d’une mise à jour en cours a les effets suivants sur le déploiement :
- Toutes les instances de rôle n’ayant pas été mises à jour ou à niveau vers la nouvelle version ne sont ni mises à jour ni mises à niveau, car les instances s’exécutent déjà sur la version cible du service.
- Toutes les instances de rôle déjà mises à jour ou à niveau vers la nouvelle version du fichier de package de service (*.cspkg) ou du fichier de configuration (*.cscfg) (ou les deux) sont rétablies à la version précédant la mise à niveau de ces fichiers.
Les fonctionnalités suivantes fournissent cette capacité :
L’opération Restaurer la mise à jour ou la mise à niveau, qui peut être appelée sur une mise à jour de configuration (déclenchée en appelant Changer la configuration du déploiement) ou une mise à niveau (déclenchée en appelant Mettre à niveau un déploiement) tant qu’il reste au moins une instance du service qui n’a pas encore été mise à jour vers la nouvelle version.
L’élément Verrouillé et l’élément RollbackAllowed, qui sont retournés comme parties intégrantes du corps de réponse des opérations Obtention du déploiement et Obtention des propriétés de service cloud :
- L’élément Verrouillé permet de détecter si une opération de mutation peut être appelée sur un déploiement donné.
- L’élément RollbackAllowed vous permet de détecter lorsque l’opération de restauration de mise à jour ou de mise à niveau peut être appelée sur un déploiement donné.
Pour effectuer une restauration, il est inutile de vérifier les éléments Locked et RollbackAllowed. Il suffit de vérifier que RollbackAllowed est défini sur true. Ces éléments sont retournés uniquement si ces méthodes sont appelées avec l’en-tête de demande défini sur « x-ms-version : 2011-10-01 » ou une version ultérieure. Pour plus d’informations sur la gestion des versions des en-têtes, consultez la gestion des versions du modèle de déploiement classique.
Dans certaines situations, la restauration d’une mise à jour ou d’une mise à niveau n’est pas prise en charge, notamment les suivantes :
- Réduction des ressources locales : si la mise à jour augmente les ressources locales d’un rôle, la plateforme Azure n’autorise pas la restauration.
- Limitations de quota : si la mise à jour correspond à une opération de réduction, vous pouvez ne plus avoir suffisamment de capacité de calcul pour effectuer l’opération de restauration. Chaque abonnement Azure a un quota associé. Le quota spécifie le nombre maximal de cœurs que tous les services hébergés appartenant à cet abonnement peuvent consommer. Si l’exécution de la restauration d’une mise à jour donnée fait dépasser votre abonnement du quota, cette restauration ne sera pas activée.
- Condition de concurrence : si la mise à jour initiale est effectuée, la restauration est impossible.
Exemple de la situation où le déploiement d’une mise à jour peut être utile si vous utilisez l’opération Mettre à niveau un déploiement en mode manuel pour contrôler la fréquence à laquelle une mise à niveau majeure est déployée sur votre service hébergé Azure.
Lors du 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 moment donné, alors que vous surveillez la mise à niveau, vous notez que certaines instances de rôle dans les premiers domaines de mise à niveau ne répondent pas, vous pouvez appeler l’opération Restaurer la mise à jour ou la mise à niveau sur le déploiement. Cette opération laisse intactes les instances qui ne sont pas mises à niveau et restaure les instances mises à niveau au package de service et à la configuration précédents.
Lancement de plusieurs opérations de mutation sur un déploiement en cours
Dans certains cas, vous souhaiterez peut-être lancer plusieurs opérations de mutation simultanées sur un déploiement en cours. Par exemple, vous pouvez effectuer une mise à jour du service et, pendant son déploiement sur votre service, vous pouvez apporter des modifications, par exemple, restaurer la mise à jour, appliquer une autre mise à jour ou encore supprimer le déploiement. Ce scénario peut se présenter si une mise à niveau de service contient un code bogué qui entraîne le plantage répété d’une instance de rôle mise à niveau. Dans ce cas, le contrôleur de structure Azure n’est pas en mesure de faire avancer cette mise à niveau parce que le nombre d’instances saines dans le domaine mis à niveau n’est pas suffisant. Cet état est connu sous le nom de déploiement bloqué. Vous pouvez débloquer le déploiement en restaurant la mise à jour ou en appliquant une nouvelle mise à jour par dessus celle qui a échoué.
Une fois que le contrôleur de structure Azure a reçu la demande initiale de mise à jour ou de mise à niveau du service, vous pouvez démarrer des opérations de mutation ultérieures. Autrement dit, vous n’avez pas besoin d’attendre la fin de l’opération initiale pour 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 se passe de façon similaire au lancement de l’opération de restauration. Si la deuxième mise à jour est en mode automatique, le premier domaine de mise à niveau est immédiatement mis à niveau, ce qui peut potentiellement aboutir à la mise hors connexion des instances de plusieurs domaines de mise à niveau en même temps.
Les opérations de mutation sont les suivantes : Modification de la configuration du déploiement, Mise à niveau du déploiement, Mise à jour de l’état du déploiement, Suppression du déploiement et Restauration de mise à jour ou de mise à niveau.
Deux opérations, Obtenir un déploiement et Obtenir les propriétés du service cloud, retournent l’indicateur Verrouillé. Vous pouvez examiner l’indicateur Verrouillé pour déterminer si vous pouvez appeler une opération de mutation sur un déploiement donné.
Pour appeler la version de ces méthodes qui retourne l’indicateur Verrouillé, vous devez définir un en-tête de requête « x-ms-version: 2011-10-01 » ou une version ultérieure. Pour plus d’informations sur la gestion des versions des en-têtes, consultez la gestion des versions du modèle de déploiement classique.
Distribution des rôles entre domaines de mise à niveau
Azure répartit les instances d’un rôle de manière égale sur un certain nombre de domaines de mise à niveau, qui peuvent être configurés dans le cadre du fichier de définition de service (.csdef). Le nombre maximal de domaines de mise à niveau est de 20, et le nombre par défaut est 5. Pour plus d’informations sur la façon de modifier le fichier de définition de service, consultez Schéma de définition du service Azure (fichier .csdef).
Par exemple, si votre rôle comporte 10 instances, par défaut, chaque domaine de mise à niveau contient deux instances. Si votre rôle comporte 14 instances, alors 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 avec un index de base zéro : l’ID du premier domaine de mise à niveau est égal à 0, et le deuxième domaine de mise à niveau possède un ID de 1 et ainsi de suite.
Le diagramme suivant montre comment les rôles d’un service contenant deux rôles sont distribués lorsque le service définit deux domaines de mise à niveau. Le service exécute huit instances de rôle web et neuf instances de rôle de travail.
Notes
Notez qu’Azure contrôle la façon dont les instances sont affectées entre d’un domaine de mise à niveau à l’autre. Il est impossible de spécifier quelles sont les instances affectées, et à quel domaine.
Étapes suivantes
Gestion des services cloud
Surveillance des services cloud
Configuration des services cloud