Résumé

  • Selon Azure, l’expiration d’une restriction temporaire a relancé en peu de temps de nombreuses mises à jour de systèmes d’exploitation des passerelles. Une modification déjà déployée avait aussi allongé le traitement des opérations de configuration.
  • La charge combinée a perturbé des opérations de gestion de plusieurs services réseau dans plusieurs régions. Sur certaines passerelles ExpressRoute, la mise à jour de l’instance redondante suivante a commencé avant le retour complet de la configuration et des routes.

La première explication d’un incident cloud est souvent la plus simple : une mise à jour a provoqué une panne. Le retour d’expérience d’Azure sur la perturbation du 30 septembre au 1er octobre décrit une interaction plus importante. Une restriction temporaire avait suspendu les mises à jour du système d’exploitation d’un groupe de passerelles. À son expiration, beaucoup d’entre elles ont repris sur une courte période. Parallèlement, une modification déjà déployée avait ralenti les opérations de configuration du plan de contrôle réseau régional. Les demandes augmentaient au moment même où chacune prenait plus de temps.

Ce n’est pas la même causalité qu’une mise à jour défectueuse. Microsoft décrit une vague de redémarrages et de demandes de configuration face à un service ralenti, alors que les mécanismes de limitation et de protection de charge n’ont pas suffisamment protégé les traitements critiques. La vague progressait région par région, d’où des horaires d’impact différents. Azure cite notamment ExpressRoute Gateway, Application Gateway, Azure Firewall, Bastion, Virtual WAN et VPN Gateway dans des régions d’Amérique, d’Europe, d’Asie-Pacifique, d’Afrique et du Moyen-Orient. Le retour public ne donne pas de relevé exhaustif client par client.

Un incident de gestion a aussi coupé certaines liaisons

De nombreuses opérations affectées étaient des actions de gestion. Pour certaines passerelles ExpressRoute, la conséquence a toutefois été une perte temporaire de connectivité avec des réseaux sur site. Selon Azure, une instance en redémarrage pouvait être déclarée saine avant le rétablissement de sa configuration et de son état de routage. La mise à jour pouvait alors passer à l’autre instance redondante. Si aucune des deux ne récupérait les routes nécessaires, la liaison était interrompue.

Après environ 30 minutes de tentatives infructueuses, les passerelles concernées ont appliqué une configuration valide conservée localement. Ce délai correspond aux tentatives de récupération mentionnées par Microsoft, pas à la durée de panne de chaque client. L’incident global a commencé à 20 h 30 UTC le 30 septembre et sa dernière vague a été atténuée à 2 h 15 UTC le 1er octobre. Azure précise que cette durée n’est pas celle de chaque client ou ressource.

La chronologie montre aussi pourquoi l’ajout de capacité n’a pas suffi. La dégradation ExpressRoute a été détectée à 20 h 43, puis les problèmes plus larges du plan de contrôle à 20 h 58. La pause de nouvelles mises à jour à 21 h 45 et le déplacement de trafic ont apporté un répit temporaire. L’enquête a associé le temps de traitement accru à une régression de performance à 23 h 55. Le retour arrière a commencé dans une région à 1 h 15, a été validé, puis étendu. L’impact a pris fin lorsque le retour arrière dans les régions concernées a été achevé à 2 h 15.

Une fenêtre de maintenance ne définit pas la reprise de la file

La documentation Azure indique que les mises à jour des passerelles peuvent inclure des correctifs, des mises à niveau réseau ou le retrait de matériel. Les clients peuvent définir des fenêtres de maintenance pour certains équipements ; cela règle le calendrier, mais ne dit pas comment un lot différé est résorbé après une pause. Microsoft annonce une reprise plus progressive, des contrôles renforcés avant la mise à jour de l’instance redondante suivante, des corrections de capacité de montée en charge et un meilleur contrôle de charge.

Ces éléments sont des mesures et des échéances rapportées par Microsoft, pas une vérification indépendante de leur achèvement.

Les recommandations de Microsoft sur les déploiements sûrs préconisent une exposition progressive, une validation de santé avant chaque étape et l’arrêt d’un déploiement en cas de problème. La question précise ici est le sens donné à « sain » : le processus a-t-il simplement redémarré, ou la configuration et les routes nécessaires au service ont-elles été récupérées et vérifiées ? La redondance n’aide que si la deuxième instance n’hérite pas de la même dépendance inachevée au plan de contrôle.

Microsoft indique que les clients ne pouvaient ni prévenir ni réduire l’impact de cet incident de service particulier. Ils peuvent néanmoins cartographier les charges dépendantes de chaque passerelle, observer leur propre plan de données séparément des opérations de gestion et configurer des alertes Service Health. Cela améliore la détection et la réponse ; cela ne transforme pas le rétablissement du fournisseur en garantie contrôlée par le client.

Sources : Retour d’expérience Azure 7Q30-010 ; Passerelles de réseau virtuel ExpressRoute ; Maintenance contrôlée par le client ; Pratiques de déploiement sûres. Cadre éditorial uniquement : Heng Lu, note 20.