Connexion
Azure à nouveau perturbé par un problème de CDN
Défaut logiciel dans le plan de contrôle, puis suppression par inadvertance d’une valeur de configuration : telles furent, le 9 octobre dernier, les sources d’un double incident ayant touché le CDN Azure Front Door.
L’accès à un grand nombre de portails de gestion de services s’en est trouvé perturbé pendant plus d’une demi-journée. L’Europe et l’Afrique furent les zones géographiques les plus touchées.
Un état de configuration invalide « loupé » par les systèmes de protection
Un nouvel incident impliquant Azure Front Door est survenu ce 29 octobre. Cette fois, l’impact n’a pas été circonscrit aux portails de gestion. Microsoft liste une quinzaine de services affectés. Parmi eux, Azure SQL Database, Azure Virtual Desktop, Copilot for Security, Purview, Sentinel et Entra ID (sur certaines composantes dont l’IAM et l’interface de gestion des utilisateurs).
Le déclencheur fut un changement de configuration de locataire Azure Front Door. Il a introduit un état invalide empêchant le chargement d’un grand nombre de nœuds. Avec, pour conséquence, une hausse des latences, voire des erreurs de connexion sur les services aval.
Microsoft a alors bloqué tout changement de configuration pour éviter la propagation de cet état défaillant. Il a ensuite amorcé un rollback vers la dernière « bonne version » de configuration. Pour éviter une surcharge, le trafic a dû être rééquilibré de façon progressive. Il s’est donc écoulé près de 10 heures entre le début de l’incident et sa résolution officielle (1 heure du matin en France ce 30 octobre, les changements de configuration par les clients étant restés bloqués un peu plus longtemps).
Cet état invalide est passé à travers les mécanismes de protection en raison d’un défaut logiciel, nous explique-t-on.
Une version défectueuse du plan de contrôle Azure Front Door
Le motif « défaut logiciel » a également été invoqué des suites de l’incident du 9 octobre. Plus précisément sur la première phase, qui a duré environ 8 heures.
Le souci se trouvait dans le plan de contrôle d’Azure Front Door, au niveau des informations communiquées au plan des données dans le cadre des opérations de création et de modification de profils CDN initiées par le client.
La version problématique du plan de contrôle avait été déployée 6 semaines en amont. Une séquence spécifique d’opérations de mise à jour de profils générait des métadonnées erronées faisant crasher le plan de données.
Les protections automatisées ont détecté le problème suffisamment tôt pour éviter une propagation au-delà du plan de données. De surcroît, l’ancienne version de plan de contrôle tournant toujours, il a été possible d’y rediriger toutes les requêtes.
Dans ce contexte, le 9 octobre, un processus d’assainissement de la configuration contenant les métadonnées erronées a été lancé. Comme le système de protection automatisé bloquait les mises à jour de profils concernées, un contournement temporaire a été mis en place. Il a toutefois ouvert la porte à la propagation des métadonnées problématiques,.. et à la perturbation d’Azure Front Door. Essentiellement, donc, en Afrique et en Europe.
La redistribution de charge qui s’est ensuivie, assortie d’une augmentation du trafic avec le démarrage des heures de bureau, a tant fait croître l’utilisation de ressources que des seuils critiques ont fini par être dépassés. Une couche de protection supplémentaire s’est alors mise en marche pour distribuer encore davantage le trafic. Il a cependant fallu des interventions manuelles lorsque le processus automatisé prenait trop de temps.
Une valeur de configuration supprimée car inconnue d’une API
En début d’après-midi (heure française), la disponibilité d’Azure Front Door était pleinement rétablie. Dans la soirée, la retour à la normale ayant été validé, Microsoft a entrepris de refaire passer tout le trafic par son CDN.
C’est là qu’un deuxième problème est survenu. Un script destiné à mettre à jour la config de load balancing a supprimé une valeur de configuration. La cause : l’API qu’il utilisait n’avait pas connaissance de cette valeur.
Les vérifications d’intégrité de l’endpoint Azure Front Door ont alors commencé à échouer. À mesure que les filtres réseau ont été mis à jour, le problème s’est propagé. Il a fallu environ 4 heures pour le résoudre. Entre-temps, environ la moitié des clients ayant utilisé les portails de gestion de services Azure ont subi une forme d’impact.
Illustration générée par IA
The post Azure à nouveau perturbé par un problème de CDN appeared first on Silicon.fr.
