Mises à niveau automatiques d’images de système d’exploitation de groupes de machines virtuelles identiques Azure

Article
10/15/2024

Notes

La plupart des étapes répertoriées dans ce document s’appliquent à Virtual Machine Scale Sets en utilisant le mode d’orchestration uniforme. Nous vous recommandons d’utiliser l’orchestration flexible pour les nouvelles charges de travail. Pour plus d’informations, consultez Modes d’orchestration pour les groupes de machines virtuelles identiques dans Azure.

L’activation des mises à niveau automatiques des images de système d’exploitation pour un groupe identique facilite la gestion des mises à jour en appliquant automatiquement et en toute sécurité chaque mise à niveau du disque du système d’exploitation à toutes les instances dans le groupe identique.

La fonctionnalité de mise à niveau automatique du système d’exploitation présente les caractéristiques suivantes :

Une fois configurée, la dernière image du système d’exploitation publiée par les éditeurs de l’image est automatiquement appliquée au groupe identique, sans aucune intervention de l’utilisateur.
Elle effectue une mise à niveau propagée de lots d’instances chaque fois qu’une nouvelle image est publiée par l’éditeur.
Elle s’intègre avec les sondes d’intégrité d’application et l’extension Intégrité de l’application.
Fonctionne pour toutes les tailles de machine virtuelle, ainsi que pour les images Windows et Linux, y compris les images personnalisées via Azure Compute Gallery.
Vous pouvez désactiver les mises à niveau automatiques à tout moment (les mises à niveau du système d’exploitation peuvent également être démarrées manuellement).
Le disque de système d’exploitation d’une machine virtuelle est remplacé par le nouveau disque de système d’exploitation créé avec la dernière version de l’image. Les extensions configurées et les scripts de données personnalisés sont exécutés. Les disques de données persistantes sont conservés.
Le séquencement d’extensions est pris en charge.
Il peut être activé sur un groupe identique de n’importe quelle taille.

Notes

Avant d’activer la mise à niveau automatique de l’image du système d’exploitation, consultez la section des conditions requises dans cette documentation.

Comment la mise à niveau automatique de l’image de système d’exploitation fonctionne-t-elle ?

Une mise à niveau fonctionne en remplaçant le disque de système d’exploitation d’une machine virtuelle par un nouveau disque créé en utilisant la version de l’image. Les extensions et scripts de données personnalisés configurés sont exécutés sur le disque du système d’exploitation, tandis que les disques de données sont conservés. Pour réduire au minimum le temps d’arrêt de l’application, les mises à niveau sont effectuées par lots, avec au maximum 20 % du groupe identique mis à niveau à la fois.

Vous devez intégrer une sonde d’intégrité d’application Azure Load Balancer ou une extension d’intégrité d’application pour suivre l’intégrité de l’application après une mise à niveau. Ceci permet à la plateforme de vérifier l’intégrité de la machine virtuelle pour garantir que les mises à jour sont appliquées de façon sécurisée. Nous vous recommandons d’incorporer une pulsation d’application pour valider la réussite de la mise à niveau.

Mises à jour selon la première disponibilité

Le modèle de première disponibilité pour les mises à jour orchestrées de la plateforme décrit ci-dessous garantit que les configurations de disponibilité dans Azure sont respectées sur plusieurs niveaux de disponibilité.

Entre les régions :

Une mise à jour est déployée sur Azure dans le monde entier de manière progressive afin d’éviter les échecs de déploiement à l’échelle d’Azure.
Une « phase » peut avoir une ou plusieurs régions, et une mise à jour ne passe pas d’une phase à l’autre tant que les machines virtuelles éligibles dans la phase précédente n’ont pas été mises à jour correctement.
Les régions appairées géographiquement ne seront pas mises à jour simultanément et ne peuvent pas être dans la même phase régionale.
La réussite d’une mise à jour est mesurée en faisant le suivi de l’intégrité d’une machine virtuelle après sa mise à jour.

Dans une région :

Les machines virtuelles de Zones de disponibilité différentes ne sont pas mises à jour simultanément avec la même mise à jour.

Dans un « groupe » :

Toutes les machines virtuelles d’un même groupe identique ne sont pas mises à jour simultanément.
Les machines virtuelles d’un groupe de machines virtuelles identiques commun sont regroupées en lots et mises à jour dans les limites du domaine de mise à jour, comme décrit ci-dessous.

Le processus de mise à jour orchestrée de la plateforme est suivi pour le déploiement des mises à niveau des images de la plateforme des systèmes d’exploitation supportés chaque mois. Pour les images personnalisées via la galerie Azure Compute Gallery, une mise à niveau d’image est lancée uniquement pour une région Azure particulière lorsque la nouvelle image est publiée et répliquée dans la région de ce groupe identique.

Mise à niveau de machines virtuelles dans un groupe identique

La région d’un groupe identique devient éligible pour obtenir des mises à niveau d’image par le biais du processus de première disponibilité pour les images de plateforme ou de la réplication de nouvelles versions d’images personnalisées pour Shared Image Gallery. La mise à niveau d’image est ensuite appliquée à un groupe identique individuel par lot, comme suit :

Avant de commencer le processus de mise à niveau, l’orchestrateur vérifie qu’il n’y a pas plus de 20 % des instances de tout le groupe identique qui se trouvent dans un état non sain (quelle qu’en soit la raison).
L’orchestrateur de mise à niveau identifie le lot de machines virtuelles à mettre à niveau, chaque lot devant compter au maximum 20 % du nombre total d’instances, avec une taille de lot minimale d’une machine virtuelle. Il n’y a pas de taille minimale requise pour les groupes identiques, et les groupes identiques comportant 5 instances ou moins ont 1 machine virtuelle par lot de mise à niveau (taille de lot minimale).
Le disque de système d’exploitation de chaque machine virtuelle du lot de mises à niveau sélectionné est remplacé par un nouveau disque de système d’exploitation créé à partir de l’image. Toutes les extensions et configurations spécifiées dans le modèle de groupe identique sont appliquées à l’instance mise à niveau.
Pour les groupes identiques configurés avec des sondes d’intégrité d’application ou l’extension Intégrité de l’application, la mise à niveau attend (jusqu’à 5 minutes) que l’instance passe à l’état sain avant de commencer la mise à niveau du lot suivant. Si une instance ne récupère pas son intégrité en 5 minutes après une mise à niveau, le disque du système d’exploitation précédent pour l’instance est restauré par défaut.
L’orchestrateur de mise à niveau suit également le pourcentage d’instances qui deviennent non saines après une mise à niveau. La mise à niveau s’arrête si plus de 20 % des instances mises à niveau passent à l’état non sain pendant le processus de mise à niveau.
Le processus ci-dessus se poursuit jusqu’à ce que toutes les instances dans le groupe identique aient été mises à niveau.

L’orchestrateur de mise à niveau du système d’exploitation du groupe identique vérifie l’intégrité de tout le groupe identique avant de procéder à la mise à niveau de chaque lot. Pendant la mise à niveau d’un lot, il peut arriver que d’autres activités de maintenance planifiées ou non planifiées aient lieu en même temps et impactent l’intégrité des instances du groupe identique. Si c’est le cas et que plus de 20 % des instances du groupe identique passent à l’état non sain, la mise à niveau du groupe identique s’arrête à la fin du lot en cours.

Pour modifier les paramètres par défaut associés aux mises à niveau propagées, consultez la Stratégie de mise à niveau propagée d’Azure.

Notes

La mise à niveau automatique du système d’exploitation ne met pas à niveau la référence SKU d’image de référence sur le groupe identique. Pour modifier la référence SKU (par exemple, Ubuntu 18.04-LTS à 20.04-LTS), vous devez mettre à jour le modèle de groupe de machines virtuelles directement avec la référence SKU d’image souhaitée. L’éditeur d’images et l’offre ne peuvent pas être modifiés pour un groupe identique existant.

Mise à niveau de l’image du système d’exploitation par rapport à la réinitialisation

La mise à niveau de l’image du système d’exploitation et le réimageage sont des méthodes utilisées pour mettre à jour des machines virtuelles au sein d’un groupe identique, mais elles servent des objectifs différents et ont des impacts distincts.

La mise à niveau de l'image du système d'exploitation implique la mise à jour de l'image du système d'exploitation sous-jacent qui est utilisé pour créer de nouvelles instances dans un ensemble d'échelle. Quand vous effectuez une mise à niveau de l’image du système d’exploitation, Azure crée de nouvelles machines virtuelles avec l’image du système d’exploitation mise à jour et remplace progressivement les anciennes instances de machine virtuelle du groupe identique par les nouvelles. Ce processus est généralement effectué en phases pour garantir une haute disponibilité. Les mises à niveau d’image de système d’exploitation sont un moyen d’appliquer sans perturbation des mises à jour ou des modifications au système d’exploitation sous-jacent des machines virtuelles d’un groupe identique. Les machines virtuelles existantes ne sont pas affectées tant qu’elles ne sont pas remplacées par les nouvelles instances.

Le réimageage d’une machine virtuelle dans un groupe identique est une action plus immédiate et plus perturbatrice. Quand vous choisissez de réimager une machine virtuelle, Azure arrête l’instance de machine virtuelle sélectionnée, effectue l’opération de réinitialisation, puis redémarre la machine virtuelle en utilisant la même image de système d’exploitation. Cela réinstalle le système d’exploitation sur cette instance de machine virtuelle spécifique. Le réimageage est généralement utilisé quand vous devez dépanner ou réinitialiser une machine virtuelle spécifique en raison de problèmes liés à cette instance.

Différences clés :

La mise à niveau de l’image du système d’exploitation est un processus progressif et non perturbateur qui met à jour l’image du système d’exploitation pour le groupe de machines virtuelles identiques au fil du temps, ce qui garantit un impact minimal sur les charges de travail en cours d’exécution.
Le réimageage est une action plus immédiate et plus perturbatrice qui affecte seulement l’instance de machine virtuelle sélectionnée, en l’arrêtant temporairement et en réinstallant le système d’exploitation.

Quand utiliser chaque méthode :

Utilisez la mise à niveau de l'image du système d'exploitation lorsque vous souhaitez mettre à jour l'image du système d'exploitation pour l'ensemble du jeu d'échelle tout en maintenant la haute disponibilité.
Utilisez le réimageage quand vous avez besoin de dépanner ou de réinitialiser une machine virtuelle spécifique dans le groupe de machines virtuelles identiques.

Il est essentiel de planifier et de choisir soigneusement la méthode appropriée en fonction de vos besoins spécifiques afin de minimiser toute interruption de vos applications et services fonctionnant dans un ensemble de machines virtuelles.

Images de système d’exploitation prises en charge

Seules certaines images de plateforme de système d’exploitation sont actuellement prises en charge. Les images personnalisées sont prises en charge si le groupe identique utilise des images personnalisées via la galerie Azure Compute Gallery.

Les références SKU de plateforme suivantes sont prises en charge (et d’autres sont régulièrement ajoutées) :

Serveur de publication	Offre de système d’exploitation	Sku
Canonical	UbuntuServer	18.04-LTS
Canonical	UbuntuServer	18_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-focal	20_04-LTS
Canonical	0001-com-ubuntu-server-focal	20_04-LTS-Gen2
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS
Canonical	0001-com-ubuntu-server-jammy	22_04-LTS-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-1
MicrosoftCblMariner	Cbl-Mariner	1-Gen2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2
MicrosoftCblMariner	Cbl-Mariner	cbl-mariner-2-Gen2
MicrosoftSqlServer	Sql2017-ws2019	enterprise
MicrosoftWindowsServer	WindowsServer	2012-R2-Datacenter
MicrosoftWindowsServer	WindowsServer	2016-centre-de-données
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2016-centre-de-données-avec-conteneurs
MicrosoftWindowsServer	WindowsServer	2016-Datacenter-with-containers-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Core-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gensecond
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-gs
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-Smalldisk
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers
MicrosoftWindowsServer	WindowsServer	2019-Datacenter-with-Containers-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-smalldisk-g2
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-core-smalldisk
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-g2
MicrosoftWindowsServer	WindowsServer	Datacenter-core-20h2-with-containers-smalldisk-gs
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition
MicrosoftWindowsServer	WindowsServer	2022-Datacenter-azure-edition-smalldisk
Mirantis	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0
Mirantis	Windows_with_Mirantis_Container_Runtime_2019	win_2019_mcr_23_0_gen2

Conditions requises pour la configuration de la mise à niveau automatique d’image de système d’exploitation

La propriété de version de l’image doit être définie sur latest.
Vous devez utiliser des sondes d’intégrité d’application ou l’extension Intégrité de l’application pour des groupes identiques autres que Service Fabric. Pour connaître les exigences applicables à Service Fabric, consultez Exigence pour Service Fabric.
Utilisez l’API de calcul de la version 2018-10-01 ou ultérieure.
Assurez-vous que les ressources externes spécifiées dans le modèle de groupe identique sont disponibles et à jour. Il s’agit par exemple de l’URI SAP pour l’amorçage de la charge utile dans les propriétés de l’extension de machine virtuelle, de la charge utile dans un compte de stockage, de références à des secrets dans le modèle, etc.
Pour les groupes identiques utilisant des machines virtuelles Windows, à partir de la version 2019-03-01 de l’API de calcul, la propriété virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates doit avoir la valeur false dans la définition du modèle de groupe identique. La propriété enableAutomaticUpdates active les mises à jour correctives dans les machines virtuelles où « Windows Update » applique les correctifs du système d’exploitation sans remplacer le disque du système d’exploitation. Une fois les mises à niveau automatiques d’images de système d’exploitation activées sur votre groupe identique, ce qui peut être effectué en définissant automaticOSUpgradePolicy.enableAutomaticOSUpgrade sur true, un processus de mise à jour corrective supplémentaire via Windows Update n’est pas nécessaire.
Le mode d’orchestration des correctifs ne doit pas être défini sur AutomaticByPlatform dans la définition du modèle de groupe identique. Avec les mises à niveau automatiques des images de système d’exploitation activées sur votre groupe identique, un processus d’orchestration des correctifs de plateforme n’est pas nécessaire.

Remarque

Une fois qu’un disque de système d’exploitation est remplacé via une nouvelle image ou une mise à niveau, les lettres de lecteur de disques de données attachés peuvent être réaffectées. Pour conserver les mêmes lettres de lecteur pour des disques attachés, il est recommandé d’utiliser un script de démarrage personnalisé.

Exigence pour Service Fabric

Si vous utilisez Service Fabric, assurez-vous que les conditions suivantes sont remplies :

Le niveau de durabilité de Service Fabric est Silver ou Gold. Si le niveau de durabilité de Service Fabric est Bronze, seuls les types de nœuds sans état prennent en charge les mises à niveau automatiques de l’image du système d’exploitation.
L’extension Service Fabric sur la définition du modèle de groupe identique doit avoir TypeHandlerVersion 1.1 ou version ultérieure.
Le niveau de durabilité doit être identique au cluster Service Fabric et à l’extension de Service Fabric de la définition du modèle de groupe identique.
Des sondes d’intégrité supplémentaires ou l’utilisation de l’extension d’intégrité d’application ne sont pas nécessaires pour la durabilité de niveau Silver ou Gold. La durabilité de niveau Bronze avec des types de nœuds uniquement sans état requiert une sonde d’intégrité supplémentaire.
La propriété virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates doit avoir la valeur false dans la définition du modèle de groupe identique. La propriété enableAutomaticUpdates active la mise à jour corrective dans la machine virtuelle à l’aide de « Windows Update » et n’est pas prise en charge sur les groupes identiques Service Fabric. Vous devez utiliser la propriété automaticOSUpgradePolicy.enableAutomaticOSUpgrade à la place.

Vérifiez que les paramètres de durabilité ne sont pas incompatibles avec le cluster Service Fabric et l’extension Service Fabric, car une incompatibilité entraîne des erreurs de mise à niveau. Les niveaux de durabilité peuvent être modifiés selon les instructions indiquées surcette page.

Mise à niveau automatique de l’image du système d’exploitation pour les images personnalisées

La mise à niveau automatique de l’image du système d’exploitation est prise en charge pour les images personnalisées déployées via la galerie Azure Compute Gallery. Les autres images personnalisées ne sont pas prises en charge pour les mises à niveau automatiques de l’image du système d’exploitation.

Exigences supplémentaires pour les images personnalisées

Le processus de paramétrage et de configuration de la mise à niveau automatique de l’image du système d’exploitation est le même pour tous les groupes identiques, comme indiqué dans la section Configuration de cette page.
Les instances de groupes identiques configurées pour les mises à niveau automatiques de l’image du système d’exploitation sont mises à niveau vers la version de l’image d’Azure Compute Gallery quand une nouvelle version de l’image est publiée et répliquée dans la région de ce groupe identique. Si la nouvelle image n’est pas répliquée vers la région où le groupe est déployé, les instances du groupe identique ne sont pas mises à niveau vers la version. La réplication régionale d’images vous permet de contrôler le déploiement de la nouvelle image pour vos groupes identiques.
La nouvelle version de l’image ne doit pas être exclue de la version pour cette image de la galerie. Les versions d’image exclues de la version de l’image de la galerie ne sont pas déployées dans le groupe identique via la mise à niveau automatique de l’image du système d’exploitation.

Remarque

Un groupe identique peut nécessiter jusqu’à 3 heures pour lancer le premier déploiement de mise à niveau d’une image après la première configuration les mises à niveau automatiques du système d’exploitation pour le groupe identique, en raison de certains facteurs tels que les fenêtres de maintenance ou d’autres restrictions. Les clients sur la dernière image peuvent ne pas bénéficier d’une mise à niveau tant qu’une nouvelle image n’est pas disponible.

Configurer la mise à niveau automatique d’image de système d’exploitation

Pour configurer la mise à niveau automatique d’image de système d’exploitation, vérifiez que la propriété automaticOSUpgradePolicy.enableAutomaticOSUpgrade est définie sur true dans la définition du modèle de groupe identique.

Notes

Le mode de stratégie de mise à niveau et la stratégie de mise à niveau automatique du système d’exploitation sont des paramètres distincts et contrôlent différents aspects du groupe identique. Quand il y a des modifications dans le modèle de groupe identique, la stratégie de mise à niveau mode détermine ce qui se passe pour les instances existantes dans le groupe identique. Toutefois, la stratégie enableAutomaticOSUpgrade de mise à niveau automatique du système d’exploitation est spécifique à l’image du système d’exploitation et effectue le suivi des modifications apportées par l’éditeur d’images et détermine ce qui se passe lorsqu’il existe une mise à jour de l’image.

Remarque

Si la valeur enableAutomaticOSUpgrade est true, enableAutomaticUpdates est automatiquement définie sur false et ne peut pas être définie sur true.

API REST

L’exemple suivant montre comment activer les mises à niveau automatiques du système d’exploitation pour un modèle de groupe identique :

PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`

{
  "properties": {
    "upgradePolicy": {
      "automaticOSUpgradePolicy": {
        "enableAutomaticOSUpgrade":  true
      }
    }
  }
}

Azure PowerShell

Utilisez l’applet de commande New-AzVmss pour configurer les mises à niveau automatiques de l’image du système d’exploitation pour votre groupe identique lors de l’approvisionnement. L’exemple suivant configure les mises à niveau automatiques pour le groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Utilisez la cmdlet Update-AzVmss pour configurer les mises à niveau automatiques d’images du système d’exploitation pour votre groupe identique existant. L’exemple suivant configure les mises à niveau automatiques pour le groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Azure CLI 2.0

Utilisez az vmss créez des pour configurer les mises à niveau automatiques d’images du système d’exploitation pour votre groupe identique lors de l’approvisionnement. Utilisez Azure CLI 2.0.47 ou une version ultérieure. L’exemple suivant configure les mises à niveau automatiques pour le groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Utilisez az vmss update pour configurer les mises à niveau automatiques de l’image du système d’exploitation pour votre groupe identique existant. Utilisez Azure CLI 2.0.47 ou une version ultérieure. L’exemple suivant configure les mises à niveau automatiques pour le groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Remarque

Après la configuration des mises à niveau automatiques d’image de système d’exploitation pour votre groupe identique, vous devez également appliquer aux machines virtuelles du groupe identique le dernier modèle de groupe identique si votre groupe identique utilise la stratégie de mise à jour « Manuelle ».

Modèles ARM

L’exemple suivant décrit comment définir des mises à niveau automatiques du système d’exploitation sur un modèle de groupe identique via des modèles Azure Resource Manager (modèles ARM) :

"properties": {
   "upgradePolicy": {
     "mode": "Automatic",
     "RollingUpgradePolicy": {
         "BatchInstancePercent": 20,
         "MaxUnhealthyInstancePercent": 25,
         "MaxUnhealthyUpgradedInstancePercent": 25,
         "PauseTimeBetweenBatches": "PT0S"
     },
    "automaticOSUpgradePolicy": {
      "enableAutomaticOSUpgrade": true,
        "useRollingUpgradePolicy": true,
        "disableAutomaticRollback": false
    }
  },
  },
"imagePublisher": {
   "type": "string",
   "defaultValue": "MicrosoftWindowsServer"
 },
 "imageOffer": {
   "type": "string",
   "defaultValue": "WindowsServer"
 },
 "imageSku": {
   "type": "string",
   "defaultValue": "2022-datacenter"
 },
 "imageOSVersion": {
   "type": "string",
   "defaultValue": "latest"
 }

Bicep

L’exemple suivant montre comment activer les mises à niveau automatiques du système d’exploitation pour un modèle de groupe identique via Bicep :

properties: {
    overprovision: overProvision
    upgradePolicy: {
      mode: 'Automatic'
      automaticOSUpgradePolicy: {
        enableAutomaticOSUpgrade: true
      }
    }
}

Utilisation de l’Extension d’intégrité d’application

Lors d’une mise à niveau du système d’exploitation, les machines virtuelles d’un groupe identique sont mises à niveau un lot à la fois. La mise à niveau doit se poursuivre seulement si l’application du client est saine sur les machines virtuelles mises à niveau. Nous recommandons que l’application envoie des signaux d’intégrité au moteur de mise à niveau du système d’exploitation pour le groupe identique. Par défaut, lors des mises à niveau du système d’exploitation, la plateforme vérifie l’état d’alimentation de la machine virtuelle et l’état d’approvisionnement des extensions pour déterminer si une machine virtuelle est saine après une mise à niveau. Lors de la mise à niveau du système d’exploitation d’une machine virtuelle, le disque de système d’exploitation sur la machine virtuelle est remplacé par un nouveau disque basé sur la dernière version de l’image. Après la mise à niveau du système d’exploitation, les extensions configurées sont exécutées sur ces machines virtuelles. L’application est considérée comme saine uniquement quand toutes les extensions sur l’instance ont été correctement provisionnées.

Un groupe identique peut éventuellement être configuré avec des sondes d’intégrité d’application pour fournir à la plateforme des informations précises sur l’état actuel de l’application. Les sondes d’intégrité d’application sont des sondes d’équilibreur de charge personnalisées qui sont utilisées comme signal d’intégrité. L’application qui s’exécute sur une instance de machine virtuelle d’un groupe identique peut répondre à des requêtes HTTP ou TCP externes en indiquant si elle est saine. Pour plus d’informations sur le fonctionnement des sondes d’équilibreur de charge personnalisées, consultez Comprendre les sondes d’équilibreur de charge. Les sondes d’intégrité d’application ne sont pas prises en charge pour des groupes identiques Service Fabric. Pour les groupes identiques autres que Service Fabric, vous devez utiliser des sondes d’intégrité d’application Load Balancer ou l’extension Intégrité de l’application.

Si le groupe identique est configuré pour utiliser plusieurs groupes de sélection élective, vous devez utiliser des sondes avec un équilibreur de charge standard.

Remarque

Une seule source de monitoring de l’intégrité peut être utilisée pour un groupe de machines virtuelles identiques, soit une extension d’intégrité d’application, soit une sonde d’intégrité. Si les deux options sont activées, vous devez en supprimer une avant d’utiliser des services d’orchestration comme les réparations d’instance ou les mises à niveau automatiques du système d’exploitation.

Configuration d’une sonde d’équilibreur de charge personnalisée comme sonde d’intégrité d’application dans un groupe identique

La bonne pratique est de créer une sonde d’équilibreur de charge de manière explicite pour déterminer l’intégrité du groupe identique. Vous pouvez utiliser le même point de terminaison pour une sonde HTTP ou TCP existante, mais une sonde d’intégrité n’a pas forcément le même comportement qu’une sonde d’équilibreur de charge standard. Par exemple, une sonde d’équilibreur de charge standard signale un état non sain quand la charge sur l’instance est trop élevée, mais cela ne détermine pas forcément l’intégrité de l’instance durant une mise à niveau automatique du système d’exploitation. Configurez la sonde pour que le taux de sondage élevé soit inférieur à deux minutes.

La sonde d’équilibreur de charge peut être référencée dans la propriété networkProfile du groupe identique et être associée à un équilibreur de charge interne ou public, comme suit :

"networkProfile": {
  "healthProbe" : {
    "id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
  },
  "networkInterfaceConfigurations":
  ...
}

Notes

Lors de l’utilisation de mises à niveau automatiques du système d’exploitation avec Service Fabric, la nouvelle image du système d’exploitation est déployée, un domaine de mise à jour après l’autre, pour maintenir la haute disponibilité des services en cours d’exécution dans Service Fabric. Pour utiliser les mises à niveau automatiques du système d’exploitation dans Service Fabric, le type de nœud de votre cluster doit être configuré de façon à utiliser le niveau de durabilité Silver ou une version supérieure. Pour le niveau de durabilité Bronze, la mise à niveau automatique de l’image du système d’exploitation est uniquement prise en charge pour les types de nœud sans état. Pour plus d’informations sur les caractéristiques de la durabilité des clusters Service Fabric, consultez cette documentation.

Utilisation de l’extension Intégrité de l’application

L’extension Intégrité de l’application est déployée au sein d’une instance de groupe de machines virtuelles identiques et rend compte de l’intégrité des machines virtuelles depuis l’instance de groupe identique. Vous pouvez configurer l’extension pour sonder un point de terminaison d’application et mettre à jour l’état de l’application sur cette instance. Cet état de l’instance est vérifié par Azure pour déterminer si une instance est éligible pour des opérations de mise à niveau.

Comme l’extension rend compte de l’intégrité depuis une machine virtuelle, elle peut être utilisée dans les situations où les sondes externes telles que les sondes d’intégrité d’application (qui utilisent des sondes Azure Load Balancer personnalisées) ne peuvent pas être utilisées.

Il existe plusieurs façons de déployer l’extension Intégrité de l’application dans vos groupes identiques, comme cela est expliqué dans les exemples de cet article.

Remarque

Configurez des mesures personnalisées pour les mises à niveau progressives sur Microsoft Azure Virtual Machine Scale Sets (aperçu)

Remarque

Les mesures personnalisées pour les mises à niveau progressives sur Microsoft Azure Virtual Machine Scale Sets sont actuellement en version préliminaire. Les préversions sont à votre disposition, à condition que vous acceptiez les conditions d’utilisation supplémentaires. Certains aspects de ces fonctionnalités sont susceptibles d’être modifiés avant la mise à disposition générale.

Les mesures personnalisées pour les mises à niveau progressives vous permettent d'utiliser l'extension d'intégrité de l'application pour émettre des mesures personnalisées sur votre ensemble de machines virtuelles. Ces mesures personnalisées peuvent être utilisées pour indiquer à l’ensemble d’échelle l’ordre dans lequel les machines virtuelles doivent être mises à jour lorsqu’une mise à niveau progressive est déclenchée. Les mesures personnalisées peuvent également informer votre groupe de mise à l'échelle du moment où une mise à niveau doit être ignorée sur une instance spécifique. Cela vous permet d'avoir plus de contrôle sur la commande et le processus de mise à jour lui-même.

Les métriques personnalisées peuvent être utilisées en combinaison avec d'autres fonctionnalités de mise à niveau progressive telles que les mises à niveau automatiques du système d'exploitation, les mises à niveau automatiques des extensions et les mises à niveau progressives MaxSurge.

Pour plus d’informations, consultez Mesures personnalisées pour les mises à niveau progressives sur Virtual Machine Scale Sets.

Obtenir l’historique des mises à niveau automatiques d’image de système d’exploitation

Vous pouvez vérifier l’historique de la dernière mise à niveau du système d’exploitation effectuée dans un groupe identique à l’aide d’Azure PowerShell, d’Azure CLI 2.0 ou des API REST. Vous pouvez obtenir l’historique des cinq dernières tentatives de mise à niveau du système d’exploitation au cours des deux derniers mois.

Tenez à jour toutes les informations d’identification

Si votre groupe identique utilise des informations d’identification pour accéder à des ressources externes, comme une extension de machine virtuelle configurée pour utiliser un jeton SAP pour le compte de stockage, vérifiez que les informations d’identification sont mises à jour. Si des informations d’identification, y compris des certificats et des jetons, ont expiré, la mise à niveau échoue, et les machines virtuelles du premier lot sont laissées dans un état d’échec.

Les étapes recommandées pour récupérer des machines virtuelles et réactiver la mise à niveau automatique du système d’exploitation après un échec d’authentification des ressources sont les suivantes :

Régénérez le jeton (ou d’autres informations d’identification) qui a été passé à vos extensions.
Vérifiez que les informations d’identification utilisées pour les communications entre les machines virtuelles et les entités externes sont à jour.
Mettez à jour les extensions dans le modèle de groupe identique avec les nouveaux jetons.
Déployez le groupe identique mis à jour ; cette opération met à jour toutes les machines virtuelles, y compris celles qui sont en échec.

API REST

L’exemple suivant utilise l’API REST pour vérifier l’état du groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`

L’appel de Get retourne des propriétés similaires à l’exemple de sortie suivant :

{
	"value": [
		{
			"properties": {
        "runningStatus": {
          "code": "RollingForward",
          "startTime": "2018-07-24T17:46:06.1248429+00:00",
          "completedTime": "2018-04-21T12:29:25.0511245+00:00"
        },
        "progress": {
          "successfulInstanceCount": 16,
          "failedInstanceCount": 0,
          "inProgressInstanceCount": 4,
          "pendingInstanceCount": 0
        },
        "startedBy": "Platform",
        "targetImageReference": {
          "publisher": "MicrosoftWindowsServer",
          "offer": "WindowsServer",
          "sku": "2016-Datacenter",
          "version": "2016.127.20180613"
        },
        "rollbackInfo": {
          "successfullyRolledbackInstanceCount": 0,
          "failedRolledbackInstanceCount": 0
        }
      },
      "type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
      "location": "westeurope"
    }
  ]
}

Azure PowerShell

Utilisez l’applet de commande Get-AzVmss afin de vérifier l’historique de mise à niveau du système d’exploitation pour votre groupe identique. L’exemple suivant montre comment vérifier l’état de la mise à niveau du système d’exploitation pour un groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory

Azure CLI 2.0

Utilisez az vmss get-os-upgrade-history afin de vérifier l’historique de mise à niveau du système d’exploitation pour votre groupe identique Utilisez Azure CLI 2.0.47 ou une version ultérieure. L’exemple suivant montre comment vérifier l’état de la mise à niveau du système d’exploitation pour un groupe identique nommé myScaleSet dans le groupe de ressources appelé myResourceGroup :

az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet

Comment obtenir la dernière version d’une image de système d’exploitation de plateforme ?

Vous pouvez obtenir les versions disponibles d’image des références SKU prises en charge pour la mise à niveau automatique du système d’exploitation en utilisant les exemples ci-dessous :

API REST

GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`

Azure PowerShell

Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"

Azure CLI 2.0

az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all

Déclencher manuellement les mises à niveau d’images du système d’exploitation

Quand la mise à niveau automatique de l’image du système d’exploitation est activée sur votre groupe identique, vous n’avez pas besoin de déclencher manuellement les mises à jour. L’orchestrateur de mise à niveau du système d’exploitation applique automatiquement la dernière version disponible de l’image à vos instances de groupe identique sans aucune intervention manuelle.

Pour des cas spécifiques où vous ne voulez pas attendre que l’orchestrateur applique la dernière image, vous pouvez déclencher manuellement une mise à niveau de l’image du système d’exploitation en utilisant les exemples ci-dessous.

Remarque

Le déclencheur manuel des mises à niveau d’images du système d’exploitation ne fournit pas de fonctionnalités de restauration automatique. Si une instance ne récupère pas son intégrité après une opération de mise à niveau, son disque de système d’exploitation précédent ne peut pas être restauré.

API REST

Utilisez l’appel démarrer l’API de mise à niveau du système d’exploitation pour démarrer une mise à niveau propagée afin de déplacer toutes les instances du groupe de machines virtuelles identiques vers la dernière version disponible du système d’exploitation. Les instances qui exécutent déjà la dernière version du système d’exploitation disponible ne sont pas affectées. L’exemple suivant explique en détail comment vous pouvez démarrer une mise à niveau propagée du système d’exploitation sur un groupe identique nommé myScaleSet dans le groupe de ressources nommé myResourceGroup :

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`

Azure PowerShell

Utilisez le cmdlet de Start-AzVmssRollingOSUpgrade afin de vérifier l’historique de mise à niveau du système d’exploitation pour votre groupe identique. L’exemple suivant explique en détail comment vous pouvez démarrer une mise à niveau propagée du système d’exploitation sur un groupe identique nommé myScaleSet dans le groupe de ressources nommé myResourceGroup :

Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"

Azure CLI 2.0

Utilisez az vmss rolling-upgrade start afin de vérifier l’historique de mise à niveau du système d’exploitation pour votre groupe identique. Utilisez Azure CLI 2.0.47 ou une version ultérieure. L’exemple suivant explique en détail comment vous pouvez démarrer une mise à niveau propagée du système d’exploitation sur un groupe identique nommé myScaleSet dans le groupe de ressources nommé myResourceGroup :

az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"

Tirer parti des journaux d’activité pour les notifications de mise à niveau et les insights

Le journal d’activité est un journal d’abonnement qui fournit un aperçu de tous les événements relatifs aux abonnements qui se sont produits dans Azure. Les clients sont en mesure de :

Voir les événements liés aux opérations effectuées sur leurs ressources dans le portail Azure
Créer des groupes d’actions pour paramétrer les méthodes de notification telles que les e-mails, sms, webhooks ou ITSM
Configurer des alertes appropriées avec différents critères à l’aide du portail, d’un modèle de ressource ARM, de PowerShell ou de l’interface CLI, à envoyer à des groupes d’actions

Les clients reçoivent trois types de notifications liées à l’opération de mise à niveau automatique du système d’exploitation :

Envoi d’une demande de mise à niveau pour une ressource particulière
Résultat de l’envoi de la demande, ainsi que tous les détails de l’erreur
Résultat de l’achèvement de la mise à niveau avec tous les détails d’erreur

Configuration de groupes d’actions pour les alertes de journal d’activité

Un groupe d’actions est une collection de préférences de notification définies par le propriétaire d’un abonnement Azure. Les alertes Azure Monitor et Service Health utilisent des groupes d’actions pour avertir les utilisateurs qu’une alerte a été déclenchée.

Les groupes d’actions peuvent être créés et gérés à l’aide de :

Les clients peuvent configurer ce qui suit à l’aide de groupes d’actions :

Notifications par SMS et/ou e-mail
Webhooks : les clients peuvent attacher des webhooks à leurs runbooks Automation, et configurer leurs groupes d’actions pour déclencher les runbooks. Vous pouvez démarrer un runbook à partir d’un webhook
Connexions ITSM

Examiner et résoudre les erreurs de mise à niveau automatique

La plateforme peut retourner des erreurs sur des machines virtuelles lors de l’exécution de la mise à niveau automatique d’images avec la stratégie de mise à niveau progressive. La vue Obtenir l’instance d’une machine virtuelle contient le message d’erreur détaillé qui permet d’investiguer et de résoudre une erreur. Les Mises à niveau propagées - Obtenir la dernière peuvent fournir plus d’informations sur la configuration et l’état de la mise à niveau propagée. L'Historique Obtenir la mise à niveau du système d’exploitation fournit des détails sur la dernière opération de mise à niveau d’image sur le groupe identique. Voici les erreurs les plus courantes pouvant entraîner des mises à niveau propagées.

RollingUpgradeInProgressWithFailedUpgradedVMs

Une erreur est déclenchée pour la défaillance d’une machine virtuelle.
Le message d’erreur détaillé indique si le lancement continue/s’interrompt en fonction du seuil configuré.

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

Une erreur est déclenchée quand le pourcentage de machines virtuelles mises à niveau dépasse le seuil maximal autorisé pour les machines virtuelles non saines.
Le message d’erreur détaillé agrège l’erreur la plus courante qui aboutit à des machines virtuelles non saines. Voir MaxUnhealthyUpgradInstancePercent.

MaxUnhealthyInstancePercentExceededInRollingUpgrade

Une erreur est déclenchée quand le pourcentage de machines virtuelles non saines dépasse le seuil maximal autorisé pour des machines virtuelles non saines lors d’une mise à niveau.
Le message d’erreur détaillé affiche le pourcentage actuel de machines non saines et le pourcentage autorisé de machines virtuelles non saines qui a été configuré. Voir maxUnhealthyInstancePercent.

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

Une erreur est déclenchée quand le pourcentage de machines virtuelles non saines dépasse le seuil maximal autorisé pour des machines virtuelles non saines avant qu’une mise à niveau soit effectuée.
Le message d’erreur détaillé affiche le pourcentage actuel de machines non saines et le pourcentage autorisé de machines virtuelles non saines qui a été configuré. Voir maxUnhealthyInstancePercent.

InternalExecutionError

Une erreur est déclenchée lorsqu’une erreur non gérée, non mise en forme ou inattendue se produit pendant l’exécution.
Le message d’erreur détaillé affiche la cause de l’erreur.

RollingUpgradeTimeoutError

Une erreur est déclenchée lorsque le processus de mise à niveau propagé a expiré.
Le message d’erreur détaillé affiche la durée pendant laquelle le système a expiré après avoir tenté de mettre à jour.

Étapes suivantes

En savoir plus sur l’extension Intégrité de l’application

Partager via

Mises à niveau automatiques d’images de système d’exploitation de groupes de machines virtuelles identiques Azure

Comment la mise à niveau automatique de l’image de système d’exploitation fonctionne-t-elle ?

Mises à jour selon la première disponibilité

Mise à niveau de machines virtuelles dans un groupe identique

Mise à niveau de l’image du système d’exploitation par rapport à la réinitialisation

Images de système d’exploitation prises en charge

Conditions requises pour la configuration de la mise à niveau automatique d’image de système d’exploitation

Exigence pour Service Fabric

Mise à niveau automatique de l’image du système d’exploitation pour les images personnalisées

Exigences supplémentaires pour les images personnalisées

Configurer la mise à niveau automatique d’image de système d’exploitation

API REST

Azure PowerShell

Azure CLI 2.0

Modèles ARM

Bicep

Utilisation de l’Extension d’intégrité d’application

Configuration d’une sonde d’équilibreur de charge personnalisée comme sonde d’intégrité d’application dans un groupe identique

Utilisation de l’extension Intégrité de l’application

Configurez des mesures personnalisées pour les mises à niveau progressives sur Microsoft Azure Virtual Machine Scale Sets (aperçu)

Obtenir l’historique des mises à niveau automatiques d’image de système d’exploitation

Tenez à jour toutes les informations d’identification

API REST

Azure PowerShell

Azure CLI 2.0

Comment obtenir la dernière version d’une image de système d’exploitation de plateforme ?

API REST

Azure PowerShell

Azure CLI 2.0

Déclencher manuellement les mises à niveau d’images du système d’exploitation

API REST

Azure PowerShell

Azure CLI 2.0

Tirer parti des journaux d’activité pour les notifications de mise à niveau et les insights

Configuration de groupes d’actions pour les alertes de journal d’activité

Examiner et résoudre les erreurs de mise à niveau automatique

Étapes suivantes

Commentaires

Ressources supplémentaires