Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Applies à : ✔️ machines virtuelles Linux ✔️ machines virtuelles Windows
Résumé
Les machines virtuelles Azure peuvent parfois redémarrer sans raison apparente, sans que vous ayez initié l’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 qui s'exécute sur Azure contre les redémarrages de machine virtuelle et les temps d'arrêt consiste à configurer les machines virtuelles pour la haute disponibilité.
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 garantit qu’au cours d’un événement de maintenance planifié ou non planifié, au moins une machine virtuelle est disponible et répond aux 99,95 % Azure SLA.
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 de Azure individuelles et fournit des conseils exploitables pour 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. En particulier, l’objectif est de réduire le temps que vous passez à déterminer si la racine du problème réside dans l’application ou dans un événement à l’intérieur de la plateforme Azure. Pour plus d’informations, consultez Understand et utiliser Resource Health.
Si Azure dispose d’informations supplémentaires sur la cause racine d’une indisponibilité initiée par la plateforme pour une machine virtuelle, 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é
Resource Health alertes sont envoyées en fonction des informations activity Log. Dans certains cas, les temps d’arrêt des machines virtuelles peuvent ne pas apparaître dans le journal d’activité. Si le temps d'arrêt ne s'affiche pas dans le journal d'activité, les alertes Resource Health ne seront pas envoyées pour le temps d'arrêt. Le temps d’arrêt est toujours visible dans Resource Health.
Voici les cas où les temps d’arrêt des machines virtuelles ne s’affichent pas dans le journal d’activité :
- Lorsqu'une machine virtuelle est créée ou migrée vers un nouvel hôte, Azure plateforme n'affiche pas correctement l'état de la machine virtuelle et l'état passe à 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 de machine virtuelle qui ne s'affichent pas dans le journal d'activité sont filtrés côté plateforme Azure pour empêcher les erreurs temporaires d'afficher des temps d'arrêt incorrects aux 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 travaille sur un plan d’élimination progressive pour offrir la meilleure expérience client.
Actions et événements pouvant entraîner le redémarrage de la machine virtuelle
Maintenance planifiée
Microsoft Azure effectue régulièrement des mises à jour dans le monde entier pour améliorer la fiabilité, les performances et la sécurité de l’infrastructure hôte qui sous-tend 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.
Pour comprendre ce qu'est la maintenance planifiée d'Azure et comment cela peut affecter la disponibilité de vos machines virtuelles Linux, consultez les articles mentionnés ici. Les articles fournissent des informations générales sur le processus de maintenance planifiée Azure et sur la planification de la maintenance planifiée afin de réduire davantage l’impact.
- Maintenance planifiée pour les machines virtuelles dans Azure
- Comment planifier la maintenance planifiée sur les machines virtuelles Windows Azure
- Comment planifier la maintenance planifiée sur Azure machines virtuelles Linux
Mises à jour de préservation de la mémoire
Pour cette classe de mises à jour dans Microsoft Azure, les utilisateurs n’ont 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.
Remarque
Les machines Linux dotées de versions anciennes de noyau sont affectées par une panique du noyau pendant 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 tombe en panne après la mise à niveau d’un 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, de Azure PowerShell, de l’interface de ligne de commande ou de l’API REST, vous pouvez trouver l’événement 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 for Cloud et Windows Update
Microsoft Defender for Cloud surveille quotidiennement les machines virtuelles Windows et Linux pour les mises à jour manquantes du système d’exploitation. Defender for Cloud récupère une liste des mises à jour de sécurité et critiques disponibles à partir de Windows Update ou de Windows Server Update Services (WSUS), selon le service configuré sur une machine virtuelle Windows. Defender for Cloud vérifie également les dernières mises à jour pour les systèmes Linux. Si votre machine virtuelle ne dispose pas d’une mise à jour système, Defender for Cloud recommande d’appliquer les mises à jour système. L’application de ces mises à jour système est contrôlée via le Defender for Cloud dans le portail Azure. L’application de certaines mises à jour peut nécessiter un redémarrage des machines virtuelles. Pour plus d'informations, voir Appliquer les mises à jour système dans Microsoft Defender for Cloud.
Comme les serveurs locaux, Azure n’envoie pas de mises à jour de Windows Update vers des machines virtuelles Windows, car ces machines sont destinées à être gérées par leurs utilisateurs. Vous êtes toutefois encouragé à laisser le paramètre de Windows Update automatique activé. L’installation automatique des mises à jour à partir de Windows Update peut également entraîner des redémarrages après l’application des mises à jour. Pour plus d’informations, consultez Windows Update FAQ.
Autres situations affectant la disponibilité de votre machine virtuelle
Il existe d’autres cas dans lesquels Azure peuvent suspendre 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 qui s’exécute à l’intérieur d’un centre de données Azure. Le serveur physique exécute un agent appelé Agent hôte en plus de quelques autres composants Azure. Lorsque ces composants logiciels Azure sur le serveur physique ne répondent pas, le système de surveillance déclenche un redémarrage du serveur hôte pour tenter de récupérer. 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 une fois 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 redeploy sur la page de détails de la machine virtuelle, ou en arrêtant et en redémarrant la machine virtuelle dans 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 est lié au matériel, Azure lance une action de récupération automatique pour mettre l'hôte défectueux hors rotation pour une investigation plus approfondie. Dans le cadre de cette récupération automatique, un processus appelé réparation du service déplace automatiquement toutes les machines virtuelles sur l’hôte défectueux vers un autre sain. Ce processus est généralement terminé dans les 15 minutes, même si le temps de récupération peut varier en fonction de facteurs tels que la taille de mémoire et les méthodes de récupération de l’hôte utilisées. La réparation du service est généralement utilisée comme dernier recours pour les défaillances matérielles afin de s’assurer que les machines virtuelles continuent de fonctionner sans temps d’arrêt important.
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
Dans de rares cas, l’équipe des opérations Azure peut avoir 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
Pannes de machine virtuelle
Les machines virtuelles peuvent redémarrer en raison de problèmes internes de machine virtuelle ou de matériel, tels qu’un problème de disque de système d’exploitation, comme décrit précédemment. La charge de travail ou le rôle exécuté sur la machine virtuelle peut déclencher une vérification de bogue dans le système d’exploitation invité. Pour trouver la raison du blocage, vérifiez les journaux système et d’application pour Windows machines virtuelles et les journaux série pour les machines virtuelles Linux. La collecte d’un vidage de mémoire est généralement la meilleure façon d’identifier la cause profonde.
Pour plus d’informations, consultez les articles suivants :
Arrêt forcés relatifs au stockage
Les machines virtuelles dans Azure s’appuient sur des disques virtuels pour le système d’exploitation et le stockage de données hébergés sur l’infrastructure stockage Azure. Chaque fois que la disponibilité ou la connectivité entre la machine virtuelle et les disques virtuels associés sont affectées pendant plus de 180 secondes, la plateforme Azure effectue un arrêt forcé des machines virtuelles pour éviter toute 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 cas, un problème généralisé peut affecter plusieurs serveurs dans un centre de données Azure. Si ce problème se produit, l’équipe Azure envoie des notifications par e-mail aux abonnements concernés. Vous pouvez consulter le tableau de bord Azure Service Health et le portail Azure pour connaître l’état des pannes en cours et des incidents passés.
Diagnostiquer les redémarrages de machine virtuelle
Vous pouvez utiliser le panneau Diagnostiquer et résoudre 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 un vidage de mémoire et contactez le support technique.