Partager via

Comprendre un redémarrage du système pour Azure

  • Article

S’applique à : ✔️ Machines virtuelles Linux ✔️ Machines virtuelles Windows

Les machines virtuelles (VM) Azure peuvent parfois redémarrer sans raison apparente, même si vous n’êtes pas à l’origine d’une opération de redémarrage. Cet article répertorie les actions et les événements qui peuvent entraîner le redémarrage des machines virtuelles et présente comment éviter les problèmes de redémarrage inattendus ou réduire leur impact.

Configurer les machines virtuelles de sorte qu’elles soient compatibles avec la haute disponibilité

La meilleure façon de protéger une application en cours d’exécution sur Azure contre un redémarrage ou un arrêt de la machine virtuelle consiste à configurer une haute disponibilité sur ces machines virtuelles.

Pour assurer ce niveau de redondance de votre application, nous vous recommandons de regrouper au moins deux machines virtuelles dans un groupe à haute disponibilité. Cette configuration assure la disponibilité d’au moins une des machines virtuelles pendant un événement de maintenance planifié ou non, avec le niveau de 99,95 % stipulé dans le contrat de niveau de service (SLA) Azure.

Pour plus d’informations sur les groupes à haute disponibilité, consultez Gérer la disponibilité des machines virtuelles.

Informations sur Resource Health

Azure Resource Health est un service qui expose l’intégrité des ressources Azure individuelles et fournit des conseils applicables permettant de résoudre les problèmes. Dans un environnement cloud où il n’est pas possible d’accéder directement aux serveurs ou aux éléments d’infrastructure, l’objectif de Resource Health est de réduire le temps que vous consacrez à la résolution des problèmes. L’objectif est notamment de réduire le temps passé à déterminer si la cause du problème est liée à l’application ou à un événement interne à la plateforme Azure. Pour plus d’informations, consultez la section Understand and use Resource Health (Comprendre et utiliser Resource Health).

Si Azure possède des informations supplémentaires sur la cause profonde dʼune indisponibilité dʼune machine virtuelle déclenchée par la plateforme, ces informations peuvent être publiées dans Resource Health jusquʼà 72 heures après lʼindisponibilité initiale.

Temps d’arrêt des machines virtuelles manquants dans le journal d’activité

Les alertes Resource Health sont envoyées en fonction des informations du journal d’activité. Dans certains cas, les temps d’arrêt des machines virtuelles peuvent ne pas apparaître dans le journal d’activité. Si les temps d’arrêt n’apparaissent pas dans le journal d’activité, les alertes Resource Health ne sont pas envoyées pour les signaler. Les temps d’arrêt sont toujours visibles dans Resource Health.

Voici les cas où les temps d’arrêt des machines virtuelles ne s’affichent pas dans le journal d’activité :

  • Quand une machine virtuelle est créée ou migrée vers un nouvel hôte, la plateforme Azure n’affiche pas correctement l’état de la machine virtuelle, qui devient Inconnu. L’état de la machine virtuelle passe à Disponible une fois que tous les processus de connectivité réseau et de nœud sont établis. La période prolongée de l’état Inconnu est retirée du journal d’activité.
  • Quand l’état de disponibilité de la machine virtuelle passe de Disponible à Indisponible, puis revient à Disponible dans les 35 secondes, le temps d’arrêt ne s’affiche pas dans le journal d’activité. Ce scénario ne se produit pas si un temps d’arrêt corrélé est envoyé dans les 15 minutes précédant l’occurrence de la première transition.
  • Si l’état de la machine virtuelle passe à Inconnu, puis revient à l’état d’origine, l’état Inconnu intermittent et les transitions associées sont retirés du journal d’activité.

Les temps d’arrêt des machines virtuelles qui n’apparaissent pas dans le journal d’activité sont filtrés du côté de la plateforme Azure pour éviter que des erreurs temporaires n’affichent des temps d’arrêt incorrects pour les clients. Grâce aux investissements continus en matière de qualité d’intégrité des machines virtuelles, les filtres peuvent ne plus être nécessaires et peuvent entraîner l’absence de signalement des modifications rapides relatives à l’intégrité des machines virtuelles. Microsoft élabore actuellement un plan de suppression progressive afin d’offrir l’expérience client la plus optimale.

Actions et événements pouvant entraîner le redémarrage de la machine virtuelle

Maintenance planifiée

Microsoft Azure exécute régulièrement des mises à jour afin d’améliorer la fiabilité, les performances et la sécurité de l’infrastructure hôte qui supporte les machines virtuelles. Nombre de ces mises à jour sont exécutées sans impact sur les machines virtuelles ou les services cloud, y compris les mises à jour de préservation de la mémoire.

Toutefois, certaines mises à jour nécessitent un redémarrage. Dans ce cas, les machines virtuelles s’arrêtent pendant la mise à jour de l’infrastructure, puis redémarrent une fois cette dernière terminée.

Découvrez en quoi consiste la maintenance planifiée Azure et son incidence possible sur la disponibilité de vos machines virtuelles Linux en consultant les articles ci-dessous. Ces articles fournissent des informations sur le processus de maintenance planifiée Azure et sa planification afin de réduire davantage l’impact.

Mises à jour de préservation de la mémoire

Pour cette classe de mises à jour dans Microsoft Azure, les utilisateurs ne constatent aucun impact sur leurs machines virtuelles en cours d’exécution. La plupart de ces mises à jour sont des composants ou des services qui peuvent être mis à jour sans interférer avec l’instance en cours d’exécution. Certaines sont des mises à jour d’infrastructure de la plateforme sur le système d’exploitation hôte qui peuvent être appliquées sans requérir un redémarrage des machines virtuelles.

Ces mises à jour de préservation de la mémoire sont réalisées avec la technologie qui permet la migration en direct. Lors de sa mise à jour, la machine virtuelle est mise en pause. Cette mise en pause permet de préserver la mémoire RAM, pendant que le système d’exploitation hôte sous-jacent reçoit les correctifs et mises à jour nécessaires. La machine virtuelle redémarre généralement dans les 30 secondes suivant sa mise en pause. Une fois la machine virtuelle redémarrée, son horloge est synchronisée automatiquement.

En raison de la courte durée de la pause, le déploiement de mises à jour via ce mécanisme permet de réduire considérablement l’impact sur les machines virtuelles. Toutefois, toutes les mises à jour ne peuvent être déployées de cette manière.

Les mises à jour multi-instances (pour les machines virtuelles d’un groupe à haute disponibilité) se voient appliquer un seul domaine de mise à jour à la fois.

Note

Les machines Linux dotées de versions anciennes de noyau sont affectées par une alerte sur le noyau au cours de cette méthode de mise à jour. Pour éviter ce problème, mettez à niveau le noyau vers la version 3.10.0-327.10.1 ou une version ultérieure. Pour plus d’informations, consultez Une machine virtuelle Linux Azure sur un noyau 3.10 panique après une mise à niveau du nœud hôte.

Actions d’arrêt ou de redémarrage initiées par l’utilisateur

Si vous effectuez un redémarrage à partir du portail Azure, d’Azure PowerShell, d’une interface de ligne de commande ou d’une API REST, l’événement est consigné dans le journal d’activité Azure.

Si vous effectuez un redémarrage à partir du système d’exploitation de la machine virtuelle, l’événement est consigné dans le journal système.

Plusieurs actions de modification de la configuration peuvent également entraîner le redémarrage de la machine virtuelle. En règle générale, un message d’avertissement s’affiche, vous indiquant que l’exécution d’une action particulière entraîne un redémarrage de la machine virtuelle. Il peut s’agir d’opérations de redimensionnement de machines virtuelles, de modification du mot de passe du compte d’administration et de la définition d’une adresse IP statique.

Microsoft Defender pour le cloud et Windows Update

Microsoft Defender pour le cloud recherche quotidiennement les mises à jour manquantes du système d’exploitation sur les machines virtuelles Windows et Linux. Defender pour le cloud récupère une liste des mises à jour de sécurité et critiques disponibles dans Windows Update ou WSUS (Windows Server Update Services), selon le service configuré sur les machines virtuelles Windows. Defender pour le cloud recherche également les dernières mises à jour pour les systèmes Linux. S’il manque une mise à jour système sur votre machine virtuelle, Defender pour le cloud vous recommande de l’appliquer. L’application de ces mises à jour du système est contrôlée par Defender pour le cloud sur le portail Azure. L’application de certaines mises à jour peut nécessiter un redémarrage des machines virtuelles. Pour en savoir plus, consultez Appliquer les mises à jour système dans Microsoft Defender pour le cloud.

Comme pour les serveurs locaux, Azure n’envoie pas les mises à jour de Windows Update à des machines virtuelles Windows, car ces machines doivent être gérées par l’utilisateur. Cependant, vous êtes invité à maintenir la configuration automatique de Windows Update activée. L’installation automatique des mises à jour de Windows Update peut également entraîner des redémarrages une fois les mises à jour appliquées. Pour plus d’informations, consultez Windows Update : Forum Aux Questions.

Autres situations affectant la disponibilité de votre machine virtuelle

Il existe des autres cas dans lesquels Azure peut interrompre activement l’utilisation d’une machine virtuelle. Vous recevrez des e-mails de notification avant d’effectuer cette action pour vous donner la possibilité de résoudre les problèmes sous-jacents. Les violations de sécurité et l’expiration de modes de paiement sont des exemples de problèmes qui affectent la disponibilité d’une machine virtuelle.

Erreurs du serveur hôte

La machine virtuelle est hébergée sur un serveur physique en cours d’exécution à l’intérieur d’un centre de données Azure. Le serveur physique exécute un agent appelé Agent hôte et quelques autres composants Azure. Lorsque ces composants logiciels Azure du serveur physique ne répondent plus, le système de surveillance déclenche un redémarrage du serveur hôte pour tenter une récupération. Dans de nombreux cas, la machine virtuelle est généralement de nouveau disponible dans les dix à quinze minutes et continue à résider sur le même hôte que précédemment.

Les erreurs de serveur sont généralement dues à une défaillance matérielle telles que la défaillance d’un disque dur ou un disque SSD. Azure surveille en permanence ces occurrences, identifie les bogues sous-jacents et déploie les mises à jour après que l’atténuation a été implémentée et testée.

Étant donné que certaines erreurs du serveur hôte peuvent être spécifiques à ce serveur, une situation de redémarrage de machine virtuelle répétée pourrait être améliorée par un redéploiement manuel de celle-ci sur un autre serveur hôte. Cette opération peut être déclenchée à l’aide de l’option de redéploiement sur la page Détails de la machine virtuelle, ou par l’arrêt et le redémarrage de la machine virtuelle sur le portail Azure.

Récupération automatique

La plateforme Azure est conçue pour gérer les problèmes de nœud hôte avec un impact minimal sur les performances des machines virtuelles. Lorsqu’un nœud hôte rencontre un problème, Azure tente d’abord la méthode de récupération la moins perturbatrice, qui consiste à redémarrer l’hôte. Si le redémarrage de l’hôte n’est pas possible ou si le problème d’origine est lié au matériel, le service de plateforme guérit toutes les machines virtuelles sur l’hôte concerné sur un nœud sain. Bien que le redémarrage d’un hôte ait généralement un impact moindre, les machines virtuelles de réparation de service peuvent être plus complexes et fastidieuses, en fonction du nombre de machines virtuelles, de leurs contraintes de déploiement et de la disponibilité des ressources locales. La réparation du service est généralement utilisée comme dernier recours pour les défaillances matérielles, car elle garantit que les machines virtuelles continuent de fonctionner sans temps d’arrêt important.

Si un serveur hôte ne peut pas redémarrer, Azure lance une action de récupération automatique pour sortir l’hôte défectueux de la rotation pour un examen approfondi. Pendant ce processus de récupération automatique, toutes les machines virtuelles de l’hôte sont automatiquement déplacées vers un autre serveur hôte sain. Bien que ce processus se termine généralement dans les 15 minutes, le temps de récupération peut varier en fonction de facteurs tels que la taille de mémoire de l’hôte et les méthodes de récupération utilisées. Pour plus d’informations sur la façon dont Azure gère ces scénarios, consultez Service Healing – Récupération automatique de Machines Virtuelles.

Maintenance non planifiée

Il est rare que l’équipe d’exploitation Azure ait besoin d’effectuer des activités de maintenance pour garantir l’intégrité globale de la plateforme Azure. Ce comportement peut affecter la disponibilité de la machine virtuelle et aboutit généralement à la même action de récupération automatique que celle décrite précédemment.

La maintenance non planifiée comprend les actions suivantes :

  • Défragmentation urgente de nœud
  • Mises à jour du commutateur réseau urgente

Incidents de machine virtuelle

Des problèmes au sein d’une machine virtuelle pourraient causer son redémarrage. La charge de travail ou le rôle en cours d’exécution sur la machine virtuelle pourrait déclencher une vérification des bogues au sein du système d’exploitation invité. Pour identifier la raison de l’incident, consultez les journaux des applications et du système pour les machines virtuelles Windows et les journaux d’activité de série pour les machines virtuelles Linux.

Les machines virtuelles d’Azure reposent sur des disques virtuels pour le système d’exploitation et sur le stockage de données hébergé sur l’infrastructure de stockage Azure. Chaque fois que la disponibilité ou la connectivité entre la machine virtuelle et les disques virtuels associés est affectée pendant plus de 120 secondes, la plateforme Azure effectue un arrêt forcé des machines virtuelles afin d’éviter une altération des données. Les machines virtuelles sont automatiquement remises sous tension une fois la connectivité de stockage restaurée. La durée de l’arrêt peut être de cinq minutes ou beaucoup plus longue.

Autres incidents

Dans de rares circonstances, un problème étendu peut affecter plusieurs serveurs dans un centre de données Azure. Si cela se produit, l’équipe Azure envoie des notifications par e-mail aux abonnements concernés. Vous pouvez consulter le Tableau de bord d’intégrité des services Azure et le portail Azure pour connaître l’état des pannes en cours et des incidents passés.

Diagnostiquer les redémarrages de la machine virtuelle

Vous pouvez utiliser le panneau Diagnostiquer et résoudre disponible sur le panneau de la machine virtuelle pour exécuter des diagnostics supplémentaires. Vous pourriez en apprendre davantage sur le redémarrage récent de votre machine virtuelle. S’il existe un problème de système d’exploitation invité, collectez le vidage de la mémoire et contactez le support technique.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.