Discussion :

[Jonathan]

Google : voici ce qui a causé la grande panne de dimanche
d'après le vice-président de l'ingénierie chez Google

Dimanche dernier, il est survenu dans certaines régions des Etats-Unis, 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 lente que d'habitude, mais cela n'a probablement pas duré plus de quelques minutes. 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.

Dans un article de blog, Benjamin Treynor Sloss, 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, 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.

Pendant toute la durée de la panne, plusieurs des services de Google ont été gravement impactés. C'est le cas de YouTube qui, globalement a enregistré une baisse de 2,5 % du nombre de vues en une heure, Google Cloud Storage n'a pas non plus été épargné et a enregistré une réduction de 30 % de son trafic. Pendant que plusieurs trouvent ces explications légères et s'attendent à en avoir des plus détaillées sur les causes profondes de cette panne, Sloss fait savoir que les équipes d'ingénierie de Google continuent de travailler afin de comprendre tous les facteurs qui auraient contribué à la perte de capacité du réseau et à la lenteur de la restauration. Les conclusions de ce travail seront probablement communiquées d'ici peu.

Source : Google

Et vous ?

Qu'en pensez-vous ?
Vous êtes-vous rendus compte de cette pertubation du réseau de Google ?
Pensez-vous qu'il s'agisse simplement d'un problème lié à une configuration incorrecte de serveurs ?

Voir aussi :

Google Drive rencontre un problème majeur de spam la firme rassure et annonce la résolution du problème dans un futur proche
Mozilla revient sur la panne qui a affecté les modules complémentaires de son navigateur Firefox et donne des détails techniques
Google provoque accidentellement une panne massive d'Internet au Japon qui a duré des heures bien que l'erreur ait été corrigée après 8 minutes

[matthius]

C'est Gogole quoi !

[Mingolito]

Avant ça il y a eu aussi une grosse panne sur AWS et aussi sur Azure. Et aussi des pannes monstrueuses chez OVH, et bien d'autres...
Bref la sécurité et la tolérance de panne il faut se la faire sois même pas compter sur un seul prestataire.

[clementmarcotte]

Faut être masochiste pour faire confiance à Google. Ils sont tellement experts en espionnage, (même du courrier privé et des achats en ligne) en pannes soudaines et en erreurs supposément de bonne foi qui violent la sécurité qu'il faudrait les fuir comme de la peste.

[shadypierre]

Faut être masochiste pour faire confiance à Google. Ils sont tellement experts en espionnage, (même du courrier privé et des achats en ligne) en pannes soudaines et en erreurs supposément de bonne foi qui violent la sécurité qu'il faudrait les fuir comme de la peste.

Quel rapport ?

[Mumus18]

Source : Google

[clementmarcotte]

Quel rapport ?

C'est évident non ? On ne peut pas faire confiance à Google.

[AoCannaille]

C'est évident non ? On ne peut pas faire confiance à Google.

Mais quel rapport avec leurs pannes? Ils peuvent avoir une éthique minable tout en fournissant un service fiable et de qualité tu sais? C'est d'ailleurs un peu comme ça qu'ils se sont imposé...

[Invité]

Des pannes réseaux, il y en aura toujours

Il y en aura probablement de moins en moins parce que les très gros réseaux deviennent de plus en plus "auto-adaptatifs" (ça, c'est l'irruption du Machine Learning, de l'IA, du Predictive Analytics, etc). Par contre les pannes réseaux qui demeureront visibles seront de plus en plus violentes parce que de plus grande magnitude avec la "cloudification" des infras.

Dans le cas présent, c'est la Google Compute Engine Unit qui est partie en vrille après un changement de configuration (le GCEU, c'est le composant essentiel de l'offre IaaS du Cloud Google).

L'automatisation des changements de configuration, c'est très pratique et ça "scale" comme on dit.
Par contre, dès qu'il y a des erreurs de configuration, les problèmes se propagent très vite également

-VX

[chrtophe]

D'un autre coté, tout le réseau ne s'écroule pas. Les services sont dégradés et c'est souvent des problèmes isolés à des secteurs géographiques. Les taux de disponibilité chez Google avoisinent les 99,99%. Ca veut pas dire qu'il n'y en a pas, mais ça reste négligeable. C'est d’ailleurs ce que dit l'article.

[Bill Fassinou]

Google donne plus de détails sur l’incident de mise en réseau de ses services cloud
après l’explication de son vice-président de l’ingénierie

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