Maintenance des machines virtuelles dans Azure

S’applique à : ✔️ Machines virtuelles Linux ✔️ Machines virtuelles Windows ✔️ Ensembles de mise à l’échelle flexibles ✔️ Ensembles de mise à l’échelle uniformes

Azure met régulièrement à jour sa plateforme pour améliorer la fiabilité, le niveau de performance et la sécurité de l’infrastructure hôte des machines virtuelles. L’objectif de ces mises à jour comprend l’application d’une mise à jour corrective aux composants logiciels de l’environnement d’hébergement, la mise à niveau des composants réseau et la désactivation du matériel.

Les mises à jour affectent rarement les machines virtuelles hébergées. Lorsque les mises à jour ont un effet, Azure choisit alors la méthode ayant le moins d’impact pour l’exécution des mises à jour :

• Si une mise à jour sans redémarrage est possible, la machine virtuelle est en pause pendant la mise à jour de l’hôte ou fait l’objet d’une migration dynamique vers un hôte déjà mis à jour.

• Si la mise à jour nécessite un redémarrage, Azure vous avertit de la maintenance planifiée. Azure vous permet également de disposer d’un intervalle de temps durant lequel vous pouvez démarrer la maintenance vous-même, au moment qui vous convient. La fenêtre de maintenance automatique dépend du type de maintenance :

  • Désaffectation matérielle : la fenêtre de maintenance automatique est généralement de 14 jours.
  • Maintenance de l’hôte: La fenêtre d’auto-maintenance est généralement de 35 jours, sauf si la maintenance est urgente.

  Azure investit dans des technologies pour réduire le nombre de cas où la maintenance planifiée de la plateforme nécessite le redémarrage des machines virtuelles. Pour obtenir des instructions sur la gestion de la maintenance planifiée, consultez Gestion des notifications de maintenance planifiée à l’aide de la Azure CLI, de PowerShell ou du portail.

Cette page décrit la façon dont Azure effectue les deux types de maintenance. Pour plus d’informations sur les événements non planifiés (interruptions), consultez Gérer la disponibilité des machines virtuelles pour Windows ou l’article correspondant pour Linux.

Dans une machine virtuelle, vous pouvez recevoir une notification concernant une maintenance à venir à l’aide de Scheduled Events pour Windows ou pour Linux.

Maintenance ne nécessitant aucun redémarrage

La plupart des mises à jour de la plateforme n’affectent pas les machines virtuelles clientes. Lorsqu’une mise à jour sans impact n’est pas possible, Azure choisit alors le mécanisme ayant le moins d’impact pour les machines virtuelles clientes.

Lorsque la maintenance ayant un impact sur la machine virtuelle est nécessaire, elle est presque toujours effectuée en interrompant la machine virtuelle pendant moins de 10 secondes. Dans de rares circonstances, et pas plus d’une fois tous les 18 mois pour les tailles de machine virtuelle à usage général, Azure utilise un mécanisme qui interrompt la machine virtuelle pendant environ 30 secondes. Après toute opération d’interruption, l’horloge de la machine virtuelle est automatiquement synchronisée lors de la reprise.

La maintenance avec préservation de la mémoire fonctionne avec plus de 90 % des machines virtuelles Azure. Elle ne fonctionne pas pour les séries G, L, N et H. Pour plus d’informations, consultez les tailles de machine virtuelle qui prennent en charge la maintenance de conservation de la mémoire. Azure utilise de plus en plus les technologies de migration dynamique et améliore les mécanismes de maintenance avec préservation de la mémoire pour réduire la durée de la mise en pause.

Ces opérations de maintenance qui ne nécessitent pas de redémarrage sont appliquées à un domaine d’erreur à la fois. Elles s’arrêtent si elles reçoivent des signaux d’alerte sur l’état de santé provenant des outils de supervision de la plateforme. Les opérations de maintenance qui ne nécessitent pas de redémarrage peuvent se produire simultanément dans des régions associées ou zones de disponibilité. Pour une modification donnée, le déploiement est principalement séquencé entre les zones de disponibilité et paires de régions, mais il peut y avoir un chevauchement à la fin.

Ces types de mise à jour peuvent affecter certaines applications. Lorsque la machine virtuelle fait l’objet d’une migration dynamique vers un autre hôte, certaines charges de travail sensibles peuvent subir une légère détérioration des performances au cours des quelques minutes qui précèdent la mise en pause de la machine virtuelle. Afin de préparer la maintenance de la machine virtuelle et de réduire l’impact sur la maintenance d’Azure, essayez d’utiliser Scheduled Events pour Windows ou Linux sur de telles applications.

Pour un meilleur contrôle sur toutes les activités de maintenance, notamment les mises à jour sans impact et sans redémarrage, vous pouvez créer une fonctionnalité de configuration de maintenance. Une configuration de maintenance vous permet d’ignorer toutes les mises à jour de plateforme et d’appliquer les mises à jour à l’heure de votre choix. Pour plus d’informations, consultez Gestion des mises à jour des plateformes avec des configurations de maintenance.

Migration dynamique

La migration dynamique est une opération qui ne nécessite aucun redémarrage et qui conserve la mémoire pour la machine virtuelle. Elle entraîne une pause ou un blocage qui dure généralement moins de 5 secondes. À l’exception des séries G, L, N et H, toutes les machines virtuelles d’infrastructure as a service (IaaS) peuvent faire l’objet d’une migration en direct. La migration dynamique est disponible sur la majorité des références SKU de série M. Les machines virtuelles éligibles représentent plus de 90 % des machines virtuelles IaaS déployées sur la flotte Azure.

La plateforme Azure déclenche la migration dynamique dans les scénarios suivants :

• Maintenance planifiée
• Défaillance matérielle
• Optimisations de l’allocation

Certains scénarios de maintenance planifiée utilisent la migration dynamique. Vous pouvez utiliser Scheduled Events pour connaître à l’avance la date de démarrage des opérations de migration dynamique.

La migration dynamique peut également être utilisée pour déplacer des machines virtuelles lorsque les algorithmes Azure Machine Learning prédisent une défaillance matérielle imminente ou une optimisation des allocations de machines virtuelles. Pour plus d’informations sur la modélisation prédictive détectant les instances de matériel détérioré, consultez Améliorer la résilience des machines virtuelles Azure grâce à la migration dynamique et au Machine Learning prédictif. Les notifications de migration dynamique s’affichent sur le portail Azure, dans les journaux Monitor et Service Health ainsi que dans Scheduled Events si vous utilisez ces services.

Résilience des connexions TCP pendant la migration dynamique

Les applications qui gèrent des connexions TCP de longue durée, telles que des serveurs de base de données, des répartiteurs de messages et des couches de mise en cache, peuvent rencontrer des interruptions de connexion pendant la migration dynamique. Pendant que la pause de machine virtuelle est généralement inférieure à 5 secondes, le comportement de la pile TCP pendant et après la pause peut étendre le temps de récupération au niveau de l’application s’il n’est pas traité.

Comment la migration dynamique affecte les connexions TCP :

• Pendant la pause, les segments TCP en cours d’exécution ne sont pas reconnus par la machine virtuelle de migration.
• Le côté émetteur (client ou sonde d’intégrité de l’équilibreur de charge) entame la retransmission TCP avec une temporisation exponentielle.
• Azure Standard Load Balancer envoie un protocole TCP RST aux connexions inactives qui dépassent le délai d’inactivité configuré. Toutefois, pour les connexions actives avec des données en cours de vol, l’équilibreur de charge n’envoie pas de RST TCP pendant la pause de migration. La connexion reste ouverte, mais ne répond pas, et le client n’a aucun signal immédiat de défaillance.
• Sans réglage au niveau de l’application, le comportement de retransmission TCP par défaut (tcp_retries2 = 15 sur Linux) peut retarder la détection des défaillances de connexion d’environ 15 minutes.

Réduisez le rayon d’explosion avec des déploiements à plusieurs instances :

Avant d’appliquer des atténuations au niveau TCP, tenez compte de la base de référence architecturale. La migration à chaud affecte une seule machine virtuelle à la fois au sein d'un groupe à haute disponibilité ou d'un Virtual Machine Scale Set. La répartition des connexions entre plusieurs instances principales limite l’impact d’un événement de migration unique :

• Un groupe de mise à l'échelle comportant trois instances signifie que chaque événement de migration affecte au maximum un tiers des connexions actives.
• Le déploiement sur Zones de disponibilité garantit que les migrations dans différentes zones ne se chevauchent pas.
• Les clients disposant de pools de connexions distribués sur plusieurs back-ends se récupèrent plus rapidement, car les connexions non affectées continuent de traiter immédiatement les demandes.

Pendant la pause de la machine virtuelle, les sondes d’intégrité d’Azure Standard Load Balancer vers l’instance de backend suspendue échouent également. L’équilibreur de charge marque le back-end comme non sain dans environ 10 secondes (deux échecs de sonde consécutifs à l’intervalle par défaut de 5 secondes) et arrête le routage de nouvelles connexions vers celui-ci. Cette condition signifie que de nouvelles connexions sont naturellement protégées. Les atténuations TCP décrites dans cet article traitent les connexions existantes qui ont déjà été établies avant le début de la migration.

Atténuations recommandées :

Les atténuations suivantes sont complémentaires. Lorsqu’ils sont implémentés ensemble, ils réduisent l’impact d’un événement de migration en direct de minutes de temps d’arrêt potentiel à secondes de récupération automatique.

Atténuation 1 : TCP_USER_TIMEOUT (détection la plus rapide)

TCP_USER_TIMEOUT contrôle la durée pendant laquelle le noyau attend l’accusé de réception des données transmises avant de déclarer une connexion morte. La définition de ce paramètre sur 30 secondes (3 0000 ms) par socket réduit considérablement le temps de détection.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Vous pouvez également réduire le nombre de retransmissions à l’échelle du système :

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

considérations Windows :

L’option TCP_USER_TIMEOUT de socket est spécifique à Linux. Sur Windows, le comportement de retransmission TCP est contrôlé différemment :

• Windows utilise par défaut 5 retransmissions (TcpMaxDataRetransmissions), ce qui fournit déjà environ 25 à 50 secondes de temps de détection sans aucun réglage.
• Pour réduire davantage le temps de détection sur Windows, ajustez le Registre :

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

Avec TcpMaxDataRetransmissions la valeur 3, le temps de détection est réduit d’environ 10 à 20 secondes en fonction du délai de retransmission initial.

Atténuation 2 : Événements planifiés (drain proactif)

Le service Événements planifiés fournit une notification préalable avant le début d’une migration dynamique. Les applications peuvent écouter les événements Freeze et purger les connexions de manière proactive avant que la pause ne survienne.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Un événement de migration en direct s’affiche comme suit :

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Lorsqu’un Freeze événement est détecté :

1. Arrêtez d’accepter de nouvelles connexions sur le nœud concerné.
2. Évacuer les connexions existantes (demander aux clients de se reconnecter à d’autres nœuds).
3. Attendez que les opérations en cours se terminent, avec un délai d’attente limité.
4. Si vous le souhaitez, accusez réception de l’événement en renvoyant l’EventId.

Atténuation 3 : réglage du keepalive TCP

Les sondes tcp keepalive détectent les connexions qui deviennent inactives après l’événement de migration :

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Avec ces paramètres, une connexion obsolète inactive est détectée dans les 60 secondes (30 + 10 x 3). Les requêtes Keepalive sont également prises en compte dans le calcul de l'activité pour le délai d'inactivité de Standard Load Balancer, ce qui empêche ce dernier de fermer de lui-même les connexions inactives.

Atténuation 4 : logique de nouvelle tentative côté client

La logique de reconnexion et de nouvelle tentative au niveau de l’application garantit la récupération quelle que soit la méthode de détection d’échec :

1. Détecter l’erreur de connexion (délai d’expiration, RST ou connexion refusée).
2. Fermez la connexion morte et supprimez-la du pool de connexions.
3. Ouvrez une nouvelle connexion au même nœud ou à un autre nœud.
4. Réessayez l’opération avec une temporisation exponentielle.

Pour les kits SDK de base de données et les pools de connexions, activez les vérifications d’intégrité périodiques (par exemple, un test ping léger toutes les 10 à 15 secondes) pour valider les connexions de manière proactive.

Configuration du pool de connexions :

Les pools de connexions qui conservent des connexions à longue durée de vie bénéficient d’un paramètre de durée de vie maximale. Ce paramètre force le recyclage périodique des connexions, ce qui garantit qu’aucune connexion unique n’accumule les risques non liés à partir des événements de migration futurs :

La définition d’une durée de vie maximale de 30 minutes signifie que même sans vérification d’intégrité active, les connexions sont naturellement remplacées avant de pouvoir accumuler de longues périodes d’obsolescence non détectées.

Surveillance et observabilité :

Pour détecter et mesurer l’impact des événements de migration dynamique sur les connexions TCP, utilisez les approches suivantes :

• Métrique de disponibilité des machines virtuelles Azure Monitor (version préliminaire) : tombe à 0 pendant la mise en pause de la machine virtuelle. Créez une règle d’alerte sur VmAvailabilityMetric avec un seuil inférieur à 1 pour détecter les événements de migration.
• Journal d’activité des événements planifiés : Les événements de migration en direct s’affichent dans le journal d’activité sous le Microsoft.Compute fournisseur avec le nom Microsoft.Compute/virtualMachines/liveMigration/action de l’opération ou en tant qu’événements Freeze lorsqu’ils sont interrogés via le service de métadonnées.
• Taux d’erreur de connexion au niveau de l’application : Surveillez les réinitialisations de connexion TCP, les délais d’expiration et le nombre de reconnexions dans les métriques de votre application. Un pic d’erreurs de connexion lié à un dip de disponibilité de machine virtuelle confirme l’impact de la migration.
• Compteurs de retransmission TCP : Sur Linux, surveillez /proc/net/netstat le champ TCPTimeouts ou utilisez ss -ti pour observer le nombre de retransmissions sur des sockets individuels. Les retransmissions élevées pendant une fenêtre de maintenance connue indiquent que les connexions ont été affectées.

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

L’établissement d’une base de référence pour ces métriques pendant l’opération normale permet de quantifier facilement l’impact des événements de migration et de vérifier que vos atténuations fonctionnent comme prévu.

Charges de travail avec tolérance zéro pour l’interruption de la migration dynamique

Pour les charges de travail qui ne peuvent tolérer aucune interruption liée à la migration dynamique, envisagez d’utiliser des Hôtes dédiés Azure avec des Configurations de maintenance. Les hôtes dédiés vous permettent de contrôler le moment où la maintenance au niveau de l’hôte se produit, ce qui élimine les événements de migration en direct surprenants.

Maintenance nécessitant un redémarrage

Dans les rares cas où les machines virtuelles doivent redémarrer dans le cadre d’une maintenance planifiée, vous recevez une notification à l’avance. Une maintenance planifiée comprend deux phases : celle de libre-service et celle de maintenance planifiée.

Lors de la phase de libre-service, qui dure généralement quatre semaines, vous démarrez la maintenance sur vos machines virtuelles. Puisqu’il s’agit d’un libre-service, vous pouvez interroger chaque machine virtuelle pour afficher leur état et vérifier le résultat de votre dernière requête de maintenance.

Quand vous démarrez la maintenance libre-service, votre machine virtuelle est redéployée sur un nœud déjà mis à jour. Comme la machine virtuelle est redéployée, le disque temporaire est perdu et les adresses IP dynamiques publiques associées à l’interface réseau virtuelle sont mises à jour.

Si vous rencontrez une erreur lors de la maintenance en libre-service, l’opération s’interrompt, la machine virtuelle n’est pas mise à jour et vous aurez la possibilité de retenter la maintenance en libre-service.

Lorsque la phase de libre-service se termine, la phase de maintenance planifiée commence. Pendant cette phase, vous pouvez toujours consulter l’état de la phase de maintenance, mais vous ne pouvez pas lancer vous-même la maintenance.

Pour plus d’informations sur la gestion de la maintenance nécessitant un redémarrage, consultez Gestion des notifications de maintenance planifiée à l’aide d’Azure CLI, de PowerShell ou du portail.

Considérations relatives à la disponibilité lors de la maintenance planifiée

Si vous décidez d’attendre jusqu’à la phase de maintenance planifiée, plusieurs éléments sont à prendre en compte si vous voulez maintenir une haute disponibilité de vos machines virtuelles.

Régions jumelées

Chaque région Azure est jumelée à une autre région de la même zone géographique. Elles constituent une paire de régions. Durant la phase de maintenance planifiée, Azure met uniquement à jour les machines virtuelles d’une seule des régions d’une paire de régions. Par exemple, durant la mise à jour de la machine virtuelle dans la région USA Centre Nord, Azure ne met à jour simultanément aucune machine virtuelle dans la région USA Centre Sud. En revanche, les autres régions, Europe Nord par exemple, peuvent faire l’objet d’une maintenance en même temps que la région USA Est. Comprendre le fonctionnement des paires régionales peut vous aider à mieux répartir vos machines virtuelles entre les régions. Pour en savoir plus, consultez Paires régionales Azure.

Zones de disponibilité

Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Pour garantir la résilience, un minimum de trois zones distinctes sont activées dans toutes les régions.

Une zone de disponibilité combine un domaine d’erreur et un domaine de mise à jour. Si vous créez trois machines virtuelles ou plus dans trois zones d’une région Azure, vos machines virtuelles sont efficacement réparties sur trois domaines d’erreur et trois domaines de mise à jour. La plateforme Azure reconnaît cette répartition entre les domaines de mise à jour pour vous assurer que les machines virtuelles des différentes zones ne sont pas mises à jour en même temps.

Chaque mise à jour d’infrastructure est déployée par zone au sein d’une seule région. Cependant, le déploiement peut avoir lieu dans une Zone 1, en même temps qu’un autre déploiement dans une Zone 2. Les déploiements ne sont pas tous sérialisés. En revanche, un seul déploiement nécessitant un redémarrage ne déploie qu’une zone à la fois afin de limiter les risques. En règle générale, les mises à jour qui nécessitent un redémarrage sont évitées lorsque cela est possible, et Azure tente d’utiliser la migration dynamique ou de fournir le contrôle aux clients.

Ensembles échelonnables de machines virtuelles

Les groupes de machines virtuelles identiques avec orchestration Flexible sont des ressources de calcul Azure qui vous permettent de combiner la scalabilité des groupes de machines virtuelles identiques utilisant le mode d’orchestration Uniform avec les garanties de disponibilité régionale des groupes à haute disponibilité.

Avec l’orchestration Flexible, vous pouvez choisir si vos instances doivent être réparties sur plusieurs zones, ou réparties sur plusieurs domaines d’erreur au sein d’une même région.

Groupes à haute disponibilité et groupes identiques Uniform

Lorsque vous déployez une charge de travail sur des machines virtuelles Azure, vous pouvez créer des machines virtuelles dans un groupe à haute disponibilité afin de fournir une haute disponibilité pour votre application. À l’aide des groupes à haute disponibilité, vous pouvez vous assurer qu’au moins une machine virtuelle est disponible en cas de panne ou d’événements de maintenance nécessitant un redémarrage.

Au sein d’un groupe à haute disponibilité, les machines virtuelles individuelles sont réparties sur un maximum de 20 domaines de mise à jour. Durant la maintenance planifiée, un seul domaine de mise à jour est mis à jour à un moment donné. Les domaines de mise à jour ne sont pas systématiquement mis à jour de façon séquentielle.

Les groupes de machines virtuelles identiques en mode d’orchestration Uniform sont des ressources de calcul Azure que vous pouvez utiliser pour déployer et gérer un ensemble de machines virtuelles identiques comme une seule et même ressource. Le groupe identique est automatiquement déployé dans les domaines de mise à jour, comme les machines virtuelles dans un groupe à haute disponibilité. Comme pour les groupes à haute disponibilité, un seul UD est mis à jour à un moment donné dans les groupes identiques Uniform durant la maintenance planifiée.

Pour plus d’informations sur la configuration de vos machines virtuelles pour la haute disponibilité, consultez Gérer la disponibilité de vos machines virtuelles pour Windows ou l’article correspondant pour Linux.

Étapes suivantes

Pour gérer la maintenance planifiée, utilisez les Azure CLI, les Azure PowerShell ou le portail.