Forum aux questions sur les redémarrages de instance de rôle provoqués par les mises à niveau du système d’exploitation de machine virtuelle

Vous ne pouvez pas refuser les mises à jour du système d’exploitation hôte. Microsoft doit maintenir à jour les systèmes d’exploitation hôtes dans le centre de données. Vous pouvez refuser la mise à jour du système d’exploitation invité en spécifiant une version du système d’exploitation invité. Toutefois, si vous procédez ainsi, votre service ne recevra plus les mises à jour de sécurité et peut être laissé vulnérable. Pour plus d’informations, consultez Gérer une version du système d’exploitation invité.

Vous ne pouvez pas contrôler quand un seul instance ou service est mis à niveau pour le système d’exploitation hôte. La mise à niveau est démarrée sur tous les centres de données Azure à travers le monde à peu près en même temps. L’infrastructure fonctionne en continu sur la mise à niveau de chaque centre de données. En raison de la complexité de s’assurer que les règles de domaine de mise à niveau sont suivies pour tous les services cloud, ce processus prend plusieurs jours. Il n’existe aucun moyen de contrôler ou de déterminer quand un instance spécifique sera affecté. Pour contrôler la mise à jour du système d’exploitation invité, vous pouvez spécifier une version fixe du système d’exploitation invité, puis la mettre à jour chaque fois que vous êtes prêt.

Il n’existe aucune prise en charge pour la connexion à une machine virtuelle PaaS Azure via le protocole RDP (Remote Desktop Protocol) et l’installation de logiciels ou d’apporter des modifications. À tout moment, la machine virtuelle peut être reconstruite et toutes les modifications que vous apportez seront perdues. Ce scénario peut se produire si le matériel échoue et que nous devons démarrer une nouvelle machine virtuelle sur un nouveau matériel. Elle se produit également lors de la mise à jour du système d’exploitation invité, lorsque la partition Windows est reconstruite. Si vous devez installer un logiciel ou apporter des modifications à la machine virtuelle, créez une tâche de démarrage et effectuez le travail à partir de là. Ce processus garantit que lorsque la machine virtuelle est recréé, votre configuration est réexécuté.

Les mises à jour installées sur la nouvelle version du système d’exploitation invité sont disponibles publiquement et des correctifs logiciels soigneusement testés. Ces correctifs logiciels sont également déployés sur des serveurs du monde entier via Windows Update, et le risque d’effets négatifs sur votre service est faible. En ce qui concerne vos services locaux, vous devez gérer les correctifs de système d’exploitation sur les machines virtuelles Azure à l’aide d’un environnement intermédiaire dans lequel vous testez d’abord les mises à jour.

Si vous souhaitez configurer un environnement intermédiaire pour tester les mises à jour avant la production, configurez votre service de production pour utiliser une chaîne de système d’exploitation de version fixe dans le fichier .cscfg. Ensuite, lorsqu’un nouveau système d’exploitation invité est disponible, vous pouvez déployer votre service sur l’emplacement de préproduction en utilisant la version la plus récente du système d’exploitation invité. Après avoir vérifié que le service fonctionne correctement sur le système d’exploitation invité le plus récent, vous pouvez effectuer un échange d’adresses IP virtuelles. Vous pouvez également effectuer une mise à niveau sur place de votre service de production pour utiliser le système d’exploitation le plus récent.

Une idée fausse courante est que plus les mises à jour appliquées sont nombreuses, plus le processus prendra de temps. Cette hypothèse est basée sur la croyance que la mise à niveau fonctionne de la même façon qu’une mise à niveau Windows Update se produit sur votre ordinateur de bureau local. Dans une mise à niveau de Windows, de nombreuses mises à jour sont copiées sur Windows et installées en incluant les redémarrages suivants. Toutefois, ce processus n’est pas le fonctionnement de la mise à niveau dans Azure.

Lorsqu’une nouvelle version du système d’exploitation est publiée dans Azure, l’équipe du système d’exploitation prend la dernière image, applique les mises à jour, puis crée un disque dur virtuel (VHD) qui contient cette nouvelle image de base. Cette image de base est ensuite copiée dans un référentiel dans Azure. Lorsque l’infrastructure est chargée d’effectuer une mise à niveau du système d’exploitation, elle effectue d’abord une passe de copie. Dans le centre de données qui va être mis à niveau, l’infrastructure copie ce nouveau disque dur virtuel d’image de base sur le disque dur sur chaque serveur. Une fois ce processus terminé, l’infrastructure commence le processus de mise à niveau, en suivant les règles de domaine de mise à niveau habituelles.

Lorsqu’un invité va être mis à jour, l’infrastructure effectue un arrêt normal du système d’exploitation, puis démarre une nouvelle machine virtuelle à l’aide de la nouvelle image de base. Le temps nécessaire à la mise à niveau d’une machine virtuelle donnée pour un système d’exploitation invité est à peu près le même temps que celui nécessaire pour effectuer un arrêt et un redémarrage appropriés de Windows.

Le minutage d’une mise à jour du système d’exploitation hôte est différent. Lorsqu’un hôte est mis à niveau, la séquence suivante se produit :

• L’hôte envoie le message d’arrêt à chaque système d’exploitation invité s’exécutant sur cet hôte.

• Chaque système d’exploitation invité reçoit l’événement standard OnStop et le temps d’arrêt de Windows pour terminer l’arrêt.

• Une fois chaque système d’exploitation invité arrêté, le système d’exploitation hôte effectue un arrêt normal et passe par sa procédure d’arrêt normale.

• Une fois le système d’exploitation hôte arrêté, l’hôte est redémarré à l’aide de la nouvelle image de système d’exploitation.

• Une fois l’hôte opérationnel, il démarre chaque système d’exploitation invité.

Ce processus de mise à jour du système d’exploitation hôte prend généralement de 15 à 20 minutes. Le temps peut varier en fonction du nombre d’autres invités sur cet hôte et du temps nécessaire pour les traiter. Mais il y aura toujours des exceptions si une défaillance se produit sur un nœud particulier et que l’infrastructure Azure détermine que les invités sur ce nœud doivent être déplacés vers un autre nœud.

Lorsque le système d’exploitation est mis à jour, Azure Fabric effectue un arrêt approprié de votre instance de rôle. Cette pratique signifie que votre code ASP.NET recevra l’événement Application_End et que le runtime du service Azure déclenchera les Stopping événements et OnStop . Votre code disposera de cinq minutes pour terminer le travail de nettoyage avant OnStop l’arrêt du processus. Une fois votre processus hôte Azure arrêté, Windows subira un arrêt normal, qui inclut le déclenchement de la norme OnStop et des événements associés pour les services Windows.

Pour plus d’informations sur la gestion d’un arrêt de votre instance, consultez La bonne façon de gérer les événements Azure OnStop, Personnaliser le cycle de vie d’un rôle web ou de travail dans .NET et RoleEntryPoint.OnStop() Method.

Informations supplémentaires

• Redémarrages de instance de rôle provoqués par des mises à niveau du système d’exploitation de machine virtuelle 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.