Il a été constaté dimanche dernier des dysfonctionnements au sein de l’infrastructure Google Cloud Platform de la firme de Mountain View. On parle en effet d’une perturbation du réseau de Google qui a entraîné des erreurs et des ralentissements de plusieurs de ses services. Pour la plupart des utilisateurs, cela n'a pas vraiment été perceptible, il est possible qu'ils aient pu constater que les requêtes de recherche étaient un tout petit peu plus lentes que d'habitude. Par contre, pour ceux des utilisateurs qui dépendent de services hébergés dans les régions touchées par la panne, l'impact a été bien plus considérable.Il y a quelques jours, Benjamin Treynor Sloss, le vice-président de l'ingénierie chez Google, s'est excusé auprès de toutes les personnes ayant été affectées par cette panne et a également fait savoir que la principale cause de la perturbation était un changement de configuration, destiné à un petit nombre de serveurs dans une même région. En temps normal, a-t-il expliqué, tout aurait dû se passer sans aucun problème, mais la configuration a été appliquée de manière incorrecte à un plus grand nombre de serveurs dans plusieurs régions voisines, ce qui a obligé ces régions à utiliser plus de la moitié de leur capacité réseau disponible.
La capacité restante du réseau étant insuffisante pour contenir le trafic réseau en provenance et à destination de ces régions, les systèmes de réseau de Google ont donc dû effectuer un tri sur le surplus de trafic en donnant la priorité aux flux de données plus sensibles au temps de latence. L'impact a été sévère pour les plateformes à bande passante élevée telles que YouTube, mais moins pour les services à bande passante réduite tels que Google Search, qui n'a connu qu'une brève augmentation du temps de latence. Le problème en lui-même a été détecté par les équipes d'ingénierie de Google en quelques secondes, mais sa résolution a pris beaucoup plus de temps.
Dans un nouveau billet explicatif en date du 6 juin, Google s’est d’abord excusé une nouvelle fois avant d’apporter des explications plus approfondies sur l'incident du dimanche passé qui a lieu sur le service Google Cloud Platform. Pour résumer les faits, l’entreprise a rapporté que des projets Google Cloud utilisant des services dans plusieurs régions des États-Unis ont enregistré une perte de paquets élevée en raison de l'encombrement du réseau pour une durée comprise entre 3 heures 19 minutes et 4 heures 25 minutes. De plus, a-t-elle affirmé, la durée et le degré de perte de paquets varient considérablement d'une région à l'autre et sont expliqués. D'autres services Google Cloud dépendant du réseau américain de Google ont également été touchés, de même que plusieurs services Google autres que le Cloud, qui ne pouvaient pas rediriger complètement les utilisateurs vers des régions non affectées.
Les services qui ont été les plus touchés sont les services hébergés dans les régions US, mais les instances Google Cloud dans us-west1 et dans toutes les régions européennes et asiatiques n'ont pas connu d'encombrement du réseau régional, a affirmé l’entreprise. Elle a ajouté que les services Google Cloud Platform ont été affectés jusqu'à la fin des opérations d'atténuation pour chaque région. Il s’agissait des services tels que Google Compute Engine, App Engine, Cloud Endpoints, Cloud Interconnect, Cloud VPN, Console Cloud, Stackdriver Metrics, Cloud Pub/Sub, Bigquery, les instances régionales de Cloud Spanner, etc. Les services G Suite dans ces régions ont également été touchés.
« Ce fut une panne majeure, à la fois par sa portée et sa durée. Comme c'est toujours le cas dans de telles situations, plusieurs défaillances se combinent pour amplifier l'impact », a déclaré Google. Des erreurs de configuration normalement bénignes et un bogue logiciel spécifique ont été associés pour provoquer la panne. Dans un premier temps, les tâches du plan de contrôle du réseau et leur infrastructure de support dans les régions touchées ont été configurées pour être arrêtées en cas d'événement de maintenance. Ensuite, les multiples instances du logiciel de gestion de cluster exécutant le plan de contrôle du réseau ont été marquées comme pouvant être incluses dans un type d’événement de maintenance relativement rare.
Troisièmement, le logiciel qui est chargé de déclencher les événements de maintenance présentait un bogue spécifique, ce qui lui permettait de déconvertir plusieurs grappes de logiciels indépendantes à la fois, même si ces grappes se trouvaient dans des emplacements physiques différents. La propagation de la panne a été donc rapide. L’événement de maintenance mentionné précédemment a commencé dans un seul emplacement physique ; le logiciel d'automatisation a créé une liste de tâches à désorganiser à cet emplacement physique, y compris les clusters logiques exécutant des tâches de contrôle réseau. Ces clusters logiques incluaient également des tâches de contrôle de réseau dans d'autres emplacements physiques. L'automatisation a ensuite désorganisé chaque cluster logique inclus dans la portée, y compris les travaux de contrôle de réseau et leur infrastructure de support dans plusieurs emplacements physiques.
Pour remédier à la panne, Google s’est appuyé sur le principe de défense en profondeur. Plus précisément, bien que l’infrastructure de contrôle du réseau ait été conçue pour être hautement résiliente, le réseau est conçu pour « échouer de manière statique » et fonctionner pendant une période de temps sans que le plan de contrôle ne soit présent en tant que ligne de défense supplémentaire contre les défaillances. Le réseau a fonctionné normalement pendant une courte période (plusieurs minutes) après le retrait du plan de contrôle. Après cette période, le routage BGP entre les emplacements physiques impactés spécifiques a été supprimé, ce qui a entraîné une réduction importante de la capacité du réseau observée par les utilisateurs, ainsi que l'inaccessibilité de certaines régions à Google Cloud.
Les ingénieurs de Google ont ensuite tenté d’appliquer les protocoles de gestion des incidents utilisés pour le plus important incident de production. Le débogage du problème a été entravé de manière significative par l’échec des outils concurrents pour l’utilisation du réseau qui est saturé. À ce stade, a expliqué Google, ses ingénieurs ont été obligé d’arrêter le logiciel d’automatisation responsable de la maintenance et par la suite de réactiver le plan de contrôle du réseau et son infrastructure de support. Cependant, d’autres problèmes supplémentaires ont de nouveau rallongé le temps de récupération, a précisé Google.
Toutes les instances du plan de contrôle du réseau ayant été planifiées à plusieurs endroits, les données de configuration avaient été perdues et devaient être reconstruites et redistribuées. « Faire cela pendant un événement de configuration réseau aussi important, pour plusieurs emplacements, s'est avéré être une perte de temps. Néanmoins, la nouvelle configuration a commencé à être déployée juste quelques minutes après », a fait comprendre Google.
Parallèlement à ces efforts, plusieurs équipes au sein de Google ont appliqué des mesures d'atténuation spécifiques à leurs services, en éloignant le trafic des régions touchées pour lui permettre de continuer à servir ailleurs. Lorsque le plan de contrôle du réseau a été reprogrammé à chaque emplacement et que la configuration appropriée a été recréée et distribuée, la capacité du réseau a commencé à revenir en ligne. Vers la fin de l’après-midi du dimanche, a indiqué Google, la récupération de la capacité du réseau a débuté et ensuite le service complet a repris un peu plus tard. Vous pourrez obtenir plus de détails sur l’incident en accédant à la page d’explication de Google.
Source : Google
Et vous ?
Que pensez-vous des explications de Google à propos de cet incident ?Voir aussi
Google : voici ce qui a causé la grande panne de dimanche d'après le vice-président de l'ingénierie chez Google Nest : la société est morte à Google I/O 2019, avec son écosystème, ses comptes, son pare-feu de confidentialité ; place maintenant à Google Nest Google Summit Paris 2019, le grand rendez-vous annuel de l'innovation Cloud revient pour une nouvelle édition, le mardi 18 juin 2019 à Paris