Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Étudiant
    Inscrit en
    novembre 2013
    Messages
    219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2013
    Messages : 219
    Points : 6 907
    Points
    6 907

    Par défaut Google donne plus de détails sur l'incident de mise en réseau de ses services cloud

    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.

    Nom : google-apps-thumb-559_120517104011_0.jpg
Affichages : 9405
Taille : 28,3 Ko

    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

  2. #2
    Membre éprouvé

    Homme Profil pro
    Écrivain public
    Inscrit en
    août 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Écrivain public
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2005
    Messages : 151
    Points : 1 089
    Points
    1 089
    Billets dans le blog
    35

    Par défaut Google

    C'est Gogole quoi !
    Matthieu Giroux - Rennes - 13 Rue François Tanguy Prigent A 15
    Livres : editions.liberlog.org/
    Contact : matthius@framasphere.org
    Tous les liens : www.agoravox.tv/auteur/matthius

  3. #3
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    665
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 665
    Points : 2 787
    Points
    2 787

    Par défaut

    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.
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  4. #4
    Expert éminent

    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2012
    Messages
    4 730
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2012
    Messages : 4 730
    Points : 9 855
    Points
    9 855
    Billets dans le blog
    30

    Par défaut

    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.
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    Ô Saint Excel, Grand Dieu de l'Inutile.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  5. #5
    Membre actif Avatar de shadypierre
    Profil pro
    Inscrit en
    février 2009
    Messages
    274
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : février 2009
    Messages : 274
    Points : 266
    Points
    266

    Par défaut

    Citation Envoyé par clementmarcotte Voir le message
    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 ?

  6. #6
    Nouveau membre du Club Avatar de Mumus18
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2019
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2019
    Messages : 6
    Points : 29
    Points
    29

    Par défaut

    Citation Envoyé par Jonathan Voir le message
    Source : Google

  7. #7
    Expert éminent

    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2012
    Messages
    4 730
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2012
    Messages : 4 730
    Points : 9 855
    Points
    9 855
    Billets dans le blog
    30

    Par défaut

    Citation Envoyé par shadypierre Voir le message
    Quel rapport ?
    C'est évident non ? On ne peut pas faire confiance à Google.
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    Ô Saint Excel, Grand Dieu de l'Inutile.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  8. #8
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    887
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 887
    Points : 2 638
    Points
    2 638

    Par défaut

    Citation Envoyé par clementmarcotte Voir le message
    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é...

  9. #9
    Membre éclairé

    Homme Profil pro
    Architecte réseau
    Inscrit en
    avril 2018
    Messages
    362
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : avril 2018
    Messages : 362
    Points : 810
    Points
    810
    Billets dans le blog
    1

    Par défaut

    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

  10. #10
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    10 754
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 10 754
    Points : 23 973
    Points
    23 973

    Par défaut

    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  11. #11
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 703
    Points : 21 433
    Points
    21 433

    Par défaut Google donne plus de détails sur l’incident de mise en réseau de ses services cloud

    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.

    Nom : z1.png
Affichages : 2982
Taille : 46,5 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

Discussions similaires

  1. Réponses: 50
    Dernier message: 03/02/2010, 08h50
  2. Une sous-requête avec NOT IN qui me cause du souci
    Par annedeblois dans le forum Requêtes et SQL.
    Réponses: 4
    Dernier message: 23/09/2008, 14h56
  3. Application qui plante à cause des tabs ?
    Par astrolus dans le forum Windows Forms
    Réponses: 1
    Dernier message: 02/05/2008, 22h54
  4. [PHP-JS] Script qui me pose de grands problemes
    Par MadSoldier dans le forum Syntaxe
    Réponses: 3
    Dernier message: 22/06/2006, 21h33
  5. [Access] Trouver qui a le plus grand nombre de visites
    Par maxidoh dans le forum Langage SQL
    Réponses: 13
    Dernier message: 03/04/2006, 03h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo