Redémarrages d’instance de rôle provoqués par les mises à niveau du système d’exploitation de machine virtuelle Azure

Article
11/19/2024

Cet article décrit les effets des mises à niveau du système d’exploitation (OS) de machine virtuelle Microsoft Azure lors du redémarrage des instances de rôle. Il contient des détails sur les planifications de mise à niveau du système d’exploitation et de l’agent invité, les impacts et les exigences du service, la notification, la détection et la façon de résoudre les problèmes courants.

Mettre à niveau les planifications

Sur une base mensuelle environ, Microsoft publie une nouvelle version du système d’exploitation invité pour les machines virtuelles PaaS (Platform as a Service) Azure. La planification exacte varie et la tendance historique est visible dans les versions du système d’exploitation invité Azure et la matrice de compatibilité du KIT de développement logiciel (SDK). Pendant ce déploiement, azure Fabric Controller effectue deux passes (une passe de système d’exploitation hôte et une passe de système d’exploitation invité) via tous les centres de données. Une mise à jour périodique de l’agent invité Azure s’exécute également à l’intérieur de votre machine virtuelle.

Les sections suivantes fournissent plus de détails sur les deux passes de mise à niveau et la mise à niveau de l’agent invité.

Passez 1 : Système d’exploitation hôte

Le premier passe le système d’exploitation hôte. Le système d’exploitation hôte redémarre les instances de rôle et le contrôleur de structure s’assure que seules les instances d’un domaine de mise à niveau à la fois sont redémarrées. Pendant ce redémarrage, vos instances de rôle passent par le processus d’arrêt standard. Ensuite, l’événement RoleEnvironment.OnStop est exécuté pour vous donner la possibilité d’arrêter correctement l’instance.

La mise à jour du système d’exploitation hôte peut prendre plusieurs jours pour que l’infrastructure coordonne les mises à niveau sur tous les différents services hébergés et domaines de mise à niveau au sein d’un centre de données. En règle générale, différentes instances de votre déploiement sont mises à jour plusieurs heures à part.

Pour plus d’informations sur le processus de mise à niveau du système d’exploitation hôte, consultez les mises à jour de l’hôte Azure : Pourquoi, quand et comment l’article de blog Azure.

Passez 2 : système d’exploitation invité

Une fois le système d’exploitation hôte terminé la mise à niveau dans le centre de données, le système d’exploitation invité est mis à niveau pour les services configurés pour utiliser les versions automatiques du système d’exploitation invité. Cette mise à niveau continue en utilisant des règles de domaine de mise à niveau standard pour votre service. Votre machine virtuelle est redémarrée et la partition Windows (lecteur D) est réimagenée à l’aide du système d’exploitation mis à niveau.

Le processus de mise à jour du système d’exploitation invité est beaucoup plus rapide que la mise à jour du système d’exploitation hôte. Cela est dû au fait que l’infrastructure doit coordonner uniquement la mise à jour au sein de votre service hébergé et vos domaines de mise à niveau. La durée du processus de mise à jour du système d’exploitation invité pour votre service dépend en grande partie des facteurs suivants :

Nombre d’instances de rôle
Nombre de domaines de mise à niveau
Combien de temps votre service prend pour arrêter (Stopping et OnStop les événements)
Combien de temps votre service prend pour démarrer (tâches de démarrage et événement OnStart )

Agent invité

L’agent invité Azure est mis à jour tous les mois environ. Lorsque l’agent invité est mis à jour, les actions suivantes se produisent :

Le processus hôte qui exécute votre rôle (généralement WaWorkerHost ou WaWebHost) est correctement arrêté.
L’agent invité se met à jour.
Le processus hôte redémarre.

Pour plus d’informations sur le processus de l’agent invité et sur la façon dont il interagit avec votre service, consultez Workflow de l’architecture de machine virtuelle Classique Windows Azure.

Impact et exigences du service

La liste suivante décrit les impacts et les exigences de votre service cloud :

Si l’un de vos rôles n’a qu’une seule instance, votre service peut rencontrer des temps d’arrêt. Vous devez avoir au moins deux instances de chaque rôle, car le contrat de niveau de service (SLA) nécessite une durée de fonctionnement de 99,95 %.
Attendez-vous à ce que vos instances de rôle redémarrent pour la mise à jour du système d’exploitation hôte environ une fois par mois. Si vous disposez de mises à jour automatiques du système d’exploitation invité, attendez-vous à ce que vos instances redémarrent à nouveau. En règle générale, les redémarrages sont séparés de plusieurs heures. Toutefois, ce délai de temps peut changer en fonction de la composition des différents services qui existent dans un centre de données.
Votre rôle doit respecter les règles qui régissent les mises à jour du système d’exploitation hôte. En particulier, les instances de rôle doivent atteindre l’état Ready dans les 30 minutes suivant le démarrage des tâches de démarrage. Pour plus d’informations sur cette limitation, consultez Comment une mise à niveau se poursuit.
La mise à niveau du système d’exploitation hôte entraîne un redémarrage de votre instance de rôle et la mise à niveau du système d’exploitation invité provoque l’équivalent d’une réimage de votre instance. En raison de ces événements, vos instances de rôle doivent être en mesure de gérer les procédures suivantes :
- Restart
- Réinitialiser
- Recyclage

Notification

Actuellement, la plateforme Azure ne propose pas de notifications proactives lorsqu’une mise à niveau du système d’exploitation se produit. Vos instances de rôle recevront un RoleEnvironment.Stopping événement avant leur arrêt. Vous pouvez utiliser cet événement pour mettre fin correctement à tout travail effectué par l’instance de rôle ou pour informer un administrateur qu’une instance s’arrête.

Vous pouvez vous abonner au flux RSS des mises à jour du système d’exploitation Azure. Ce flux doit être mis à jour le jour même où les mises à jour du système d’exploitation commencent à être déployées dans le centre de données. Le flux ne donne généralement pas de notification proactive avancée, mais il vous aide à identifier le moment où les mises à jour se produisent. Le processus de mise à jour peut prendre plusieurs jours. Par conséquent, vous devrez peut-être attendre un ou plusieurs jours entre la mise à jour du flux RSS et le début de la mise à jour de votre service hébergé.

La liste des versions du système d’exploitation invité Azure et la liste des versions du système d’exploitation disponibles pour la sélection dans le Portail Azure sont généralement mises à jour une fois le déploiement du système d’exploitation invité terminé. Vous ne devez pas utiliser la dernière entrée de ces listes comme indication du moment où les mises à jour du système d’exploitation sont en cours.

Détection

Actuellement, il n’existe aucun moyen direct de détecter une mise à niveau du système d’exploitation hôte. Toutefois, vous pouvez voir la preuve du redémarrage dans les journaux d’activité sur la machine virtuelle. Pour ce faire, effectuez l’une des actions suivantes :

Dans l’application Observateur d’événements, recherchez l’ID d’événement 1074 dans les journaux des événements de la source d’événements USER32. Cet événement contient le message suivant :

Le processus D :\Packages\GuestAgent\WaAppAgent.exe (RD00155D50206D) a lancé l’arrêt de l’ordinateur RD00155D50206D pour le compte de l’utilisateur NT AUTHORITY\SYSTEM pour la raison suivante : Arrêt de l’API héritée

Ce message indique que l’agent invité Azure Fabric (WaAppAgent.exe) a lancé un arrêt de la machine virtuelle.
Dans un éditeur de texte, recherchez un ancien fichier journal du runtime de l’agent d’application (AppAgentRuntime.log.old) pour un _Context_Start message dans lequel il Context est égal à StopContainer(). Pour plus d’informations sur l’examen des entrées de contexte dans le journal d’exécution de l’agent d’application, consultez le scénario de résolution des problèmes 6 – Recyclage des rôles après exécution pendant un certain temps dans l’archive de blog Azure.

Problèmes courants et solutions

Les sections suivantes décrivent certains problèmes courants qui impliquent des redémarrages d’instance de rôle et la façon dont vous pouvez les résoudre. Pour plus d’informations sur les processus en cours d’exécution et l’emplacement des fichiers journaux que vous pouvez utiliser pour la résolution des problèmes, consultez Workflow de l’architecture de machine virtuelle Classique Windows Azure.

Problème 1 : Échec de l’exécution des tâches de démarrage ou du code après le redémarrage d’un système d’exploitation hôte

Les tâches de démarrage ou le code dans le ou Run la OnStart fonction peuvent échouer la deuxième fois après le redémarrage d’un système d’exploitation hôte. Le redémarrage est censé appeler vos tâches de démarrage pour qu’elles s’exécutent à nouveau. Cet échec empêche l’instance de rôle d’atteindre l’état Ready .

Que se passe-t-il si vous effectuez quelque chose dans une tâche de démarrage, puis que vous exécutez une commande qui retourne une erreur après l’exécution de la deuxième fois ? Dans ce cas, votre tâche de démarrage échoue et entraîne le recyclage de votre instance de rôle. Par exemple, si vous utilisez la commande de configuration appCMD set pour ajouter une section de configuration dans Internet Information Services (IIS), la commande échoue lors de sa deuxième exécution. La commande génère le message d’erreur « Nouvel objet ajouter des attributs requis manquants. Impossible d’ajouter une entrée de collection en double de type... Ensuite, l’instance de rôle commence à recycler.

Solution 1 : Se connecter à la machine virtuelle et déboguer l’échec du démarrage ou du code à distance

Pour résoudre ce type de défaillance, utilisez le protocole RDP (Remote Desktop Protocol) pour vous connecter à distance à la machine virtuelle. Examinez les journaux des événements pour les erreurs et vérifiez dans le fichier WaHostBootstrapper.log les échecs de tâche de démarrage. Pendant votre processus de développement et de test standard, vous devez lancer de manière proactive un redémarrage de vos instances de rôle à partir du Portail Azure. Cette étape vous aide à tester votre service pour vous assurer qu’il fonctionne correctement dans ce scénario.

Un correctif courant pour les échecs de tâche de démarrage consiste à ajouter une exit /b 0 commande à la fin de votre script de tâche de démarrage. Cette commande de sortie met fin au script à l’aide d’un code de sortie qui indique la réussite. Pour plus d’informations sur la raison pour laquelle cette commande est nécessaire, consultez Comment configurer et exécuter des tâches de démarrage pour un service cloud Azure (classique) .

Problème 2 : La tâche de démarrage ou le code ne s’exécute pas après la réimage de la partition Windows

La partition Windows (lecteur D) est généralement l’endroit où les installations du programme et les modifications du Registre sont stockées. Pendant la partie du système d’exploitation invité d’une mise à jour, la partition Windows est réimageée. Cela peut entraîner la perte de ces installations et modifications. Si le code de démarrage suppose par erreur que certaines modifications de Registre existent toujours après la réinitialisation de la partition Windows, l’instance de rôle peut ne pas fonctionner correctement. Cet échec empêche l’instance de rôle d’atteindre l’état Ready .

Par exemple, la tâche de démarrage peut apporter une modification de Registre. Ensuite, il stocke un enregistrement de cette modification sur le lecteur C ou E pour vous assurer que la modification du Registre ne s’exécute pas une seconde fois. Toutefois, la modification du Registre sur le lecteur D est perdue en raison de la réinitialisation, et la tâche de démarrage ne restaure pas ce changement de Registre, car la tâche ne pense pas qu’elle est nécessaire. La modification du Registre manquante peut éventuellement entraîner l’échec du reste de la tâche de démarrage.

Solution 2 : Tester la reimaration des instances de rôle à partir de l’Portail Azure

Pendant votre processus de développement et de test standard, vous devez lancer de manière proactive une réinitialisation de vos instances de rôle à partir de l’Portail Azure. Cette étape vous aide à tester votre service et à vous assurer qu’il fonctionne correctement dans ce scénario.

Problème 3 : Le code de démarrage prend plus de 30 minutes pour terminer

Si votre code de démarrage prend plus de 30 minutes, vous pouvez avoir plusieurs instances de rôle hors service en même temps. Ce scénario se produit généralement lorsqu’une tâche de démarrage effectue l’une des actions suivantes :

Installe un programme ou une fonctionnalité
Télécharge les données du cache
Télécharge les informations sur le site web

Solution 3 : Passer en revue les impacts et les exigences du service

Passez en revue les impacts et les exigences du service pour savoir ce qu’il faut attendre et comment vous pouvez empêcher ou atténuer les retards de démarrage.

Problème 4 : Azure ne redémarre pas le système d’exploitation hôte ou invité après une mise à jour

Dans de rares cas, Azure peut ne pas redémarrer le système d’exploitation hôte ou invité après une mise à jour. Dans ce scénario, vous verrez probablement un message « En attente de l’hôte » dans le portail qui ne change pas après 30 minutes ou plus.

Solution 4a : Corriger le code de démarrage

Si vous êtes en mesure d’utiliser le protocole RDP (Remote Desktop Protocol) pour vous connecter à l’instance de rôle, il peut y avoir un échec dans le code de démarrage que vous pouvez corriger. Pour plus d’informations sur la résolution du code de démarrage, consultez la solution 1 : Se connecter à la machine virtuelle et déboguer l’échec du démarrage ou du code à distance.

Solution 4b : Supprimer le déploiement

Si vous ne pouvez pas utiliser RDP pour vous connecter à l’instance de rôle, probablement la seule façon de récupérer l’instance consiste à supprimer le déploiement.

Problème 5 : Une ou plusieurs instances de rôle ne sont pas disponibles pendant la mise à niveau du système d’exploitation

Si des instances de rôle ne sont pas disponibles pendant la mise à niveau du système d’exploitation, cela peut entraîner une réduction de la capacité de service. Par exemple, supposons que vous disposez de deux instances d’un rôle web et que les deux instances s’exécutent généralement à 75 pour cent de l’utilisation du processeur. Si une instance est redémarrée pendant la mise à niveau, le trafic est redirigé vers l’instance restante. Cette instance ne peut pas gérer la charge supplémentaire. Cela entraîne une réduction de la disponibilité du service.

Solution 5 : Conserver suffisamment de capacité excédentaire dans votre service

Assurez-vous que votre service dispose d’une capacité excédentaire suffisante pour absorber un certain pourcentage d’instances de rôle indisponibles. Pour calculer la quantité de capacité excédentaire que vous devez mettre à disposition, divisez le nombre un par le nombre de domaines de mise à niveau. Par exemple, si vous avez deux domaines de mise à niveau, vous avez besoin de 1/2 = 50 % de capacité excédentaire pour gérer un domaine de mise à niveau devenant indisponible. Si vous avez cinq domaines de mise à niveau, vous avez besoin de 1/5 = 20 % de capacité excédentaire pour gérer la perte de disponibilité dans l’un des cinq domaines de mise à niveau.

Problème 6 : Les clients rencontrent des pannes ou des délais d’attente parce que votre site web prend trop de temps pour se réchauffer

Votre site web prend-il plusieurs minutes pour se réchauffer ? (Par exemple, le préchauffage du site web peut être constitué d’IIS standard ou de ASP.NET le chargement de précompilation et de module, ou il peut être un réchauffement d’un cache ou d’autres tâches spécifiques à l’application.) Dans ce cas, vos clients peuvent rencontrer une panne ou des délais d’attente aléatoires.

Une fois qu’une instance de rôle redémarre et que votre OnStart code termine son exécution, votre instance de rôle est restaurée dans la rotation de l’équilibreur de charge. L’instance de rôle commence ensuite à recevoir des demandes entrantes. Si votre site web se réchauffe encore, toutes ces demandes entrantes sont mises en file d’attente et expirent. Supposons que vous n’avez que deux instances de votre rôle web. Dans ce cas, l’instance IN_0 reçoit 100 % des demandes entrantes pendant le redémarrage de l’instance IN_1 pour la mise à jour du système d’exploitation invité. Toutefois, l’instance IN_0 se réchauffe toujours. Ce scénario peut entraîner une panne complète de votre service jusqu’à ce que votre site web soit terminé de se réchauffer sur les deux instances.

Solution 6 : Arrêter une instance de rôle de recevoir des demandes entrantes jusqu’à ce que la préchauffage soit terminée

Nous vous recommandons de conserver le OnStart code de gestion des événements pour votre instance de rôle jusqu’à ce que le site web termine sa préchauffage. Pour implémenter ce processus d’événement, vous pouvez utiliser l’exemple de code suivant :

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

Plus d’informations

Faq sur les redémarrages de l’instance de rôle à partir des mises à niveau du système d’exploitation des machines virtuelles Azure

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.

Partager via