Ce matin, certains découvraient que de nombreux sites et services étaient hors-ligne. Démonstration de la forte présence d'OVHcloud sur le web dans de nombreux pays. Une erreur humaine qui a mené à une panne du routage IPv4 qui intervient à quelques jours de l'entrée en bourse du roubaisien.
Ce matin, à 9h12 (heure de Paris), les réseaux sociaux s'agitent car un nombre important de sites sont inaccessibles : Assemblée nationale, Arte, Arrêt sur Images, le site open data du gouvernement… Ils seraient trop nombreux pour les citer tous. Leur point commun est vite trouvé : « l'ensemble du réseau OVH est indisponible », reconnait l'hébergeur sur son site dédié au support… qui était lui aussi inaccessible durant la panne.
Une erreur aux États-Unis fait tomber tout le réseau
Aux alentours de 10h, Octave Klaba est intervenu sur Twitter pour donner quelques précisions : « Suite à une erreur humaine durant la reconfiguration du network sur notre DC à VH (US-EST), nous avons un souci sur tout le backbone. Nous allons isoler le DC VH puis fixer la conf ». Il explique que « ces derniers jours, l’intensité des attaques DDoS a beaucoup augmenté ». Pour y faire face, l’hébergeur a décidé d’augmenter sa capacité de traitement « en ajoutant de nouvelles infrastructures dans [son] DC VH (US-EST) ».
On connait la suite : « une mauvaise configuration du routeur a provoqué la panne ». Un communiqué officiel reprenant ces éléments a par la suite été mis en ligne. Le post mortem vient d'être publié. Analyse.
Quand on vous dit de passer à IPv6
Contrairement à l’incendie de Strasbourg, aucun serveur n’a été touché physiquement : ils continuaient de tourner comme si de rien n’était, comme le confirme Stéphane Bortzmeyer (spécialiste des réseaux) sur son blog.
Il donne une précision importante : « La panne affectait en fait le routage à l'intérieur même de l'AS 16276, celui d'OVH. (Contrairement à la panne de Facebook, qui, elle, était externe.) Si IPv6 a eu une courte coupure (il est reparti au bout de sept minutes), IPv4 est resté en panne environ une heure (la reprise était vers 0825 UTC [10h25 heure française, ndlr]) ». De son côté, OVHcloud parle d’un retour à la normale à 10h22.
Dans son post mortem, l'entreprise détaille la chronologie des évènements : à 09h05 la mise à jour est effectuée comme prévu, 13 minutes plus tard elle est entrée en action, puis à 09h20 « pendant la modification de la route-map, une erreur est rencontrée : le routeur ne prend pas le dernier caractère de la commande ». Sur Twitter, Octave Klaba a évoqué une erreur de copier-coller dans la matinée avant de retirer le tweet.
L'équipe détecte rapidement le problème et le remonte afin que le processus de gestion de crise se mette en place. Un retour en arrière est tenté à 09h30 mais ne fonctionne pas, un second plan de mitigation intervient à 09h45, à 10h10 est pris la décision de débrancher le routeur posant problème, le retour des services est constaté vers 10h20.
« Tout se passait bien en IPv6, tout échouait en IPv4. Ce n'était pas spécifique au DNS, tous les services avaient le même comportement, ce qui est logique puisqu'ils dépendent tous d'IP », résume Bortzmeyer qui en profite pour lancer une petite pique à l‘hébergeur : « Il est d'ailleurs très dommage que le site web d'information d'OVH sur les travaux en cours n'ait pas d'adresse IPv6… (Idem pour les sites d'information corporate et technique) ».
Car une partie du problème était là : en cas de souci, les clients OVHcloud savent qu'il faut se rendre sur le site de statut pour savoir ce qu'il se passe... mais il était également indisponible. « OVHcloud opère un backbone global intervenant sur l'ensemble des continents. Pour s'assurer que les clients ont le meilleur accès possible, il est entièrement maillé. Par nature, ce maillage implique que tous les routeurs prenant part au backbone sont directement et indirectement connectés les uns aux autres et échangent des informations », déclare l'hébergeur.
Il ajoute que pendant la panne, toute la table de routage d'Internet était annoncée via l'IGP (Interior Gateway Protocol) OVHcloud, ce qui a surchargé la RAM et le CPU de certains routeurs et donc la panne sur IPv4. C'est l'accès physique à l'appareil défaillant qui a permis de rapidement résoudre le problème. Pour rappel, dans la panne récente de Facebook, c'est notamment l'impossibilité d'accès aux salles qui avait fait durer la situation.
OVHcloud indique désormais évaluer ses procédures de validation sur ces appareils, notamment pour ce qui concerne l'envoi et la validation des commandes exécutées, afin de les renforcer. Espérons que la généralisation d'IPv6 sur les services critiques fera aussi partie des actions prévues.
Un problème, ça peut arriver, quoi qu’en disent les yakafokons
Stéphane Bortzmeyer tient de son côté à remettre les pendules à l’heure : oui OVHcloud a planté, mais cela peut arriver : « un réseau de la taille de celui d'OVH est un objet socio-technique très complexe et qu'il est très difficile de prévoir les conséquences d'une action (ici, la maintenance) ». Il reprend ensuite le tweet de Shnoulle : « Même planifiés, testés et vérifiés : l'erreur est toujours possible. En effet : les tests ne pourront jamais tout couvrir ».
Autre précision importante, le coût : « J'utilise OVH, comme beaucoup, parce que ce n'est pas cher. Exiger une fiabilité de centrale nucléaire est irréaliste pour ce prix. S'assurer qu'un réseau fonctionne pendant 99,999 % du temps n'est pas un peu plus cher que de s'assurer qu'il fonctionne pendant 99,99 % du temps, c'est beaucoup plus cher ». Pour rappel, dans le premier cas la coupure peut être de 5,3 minutes par an, de 53 minutes dans le second.
Il faut donc choisir son hébergeur en fonction de ses besoins. Pour un site personnel ou même professionnel, on peut souvent s’accommoder d’une petite panne comme celle de ce matin tant qu’elle ne revient pas trop souvent. Par contre la situation est différente pour des sites critiques (services d’urgence par exemple).
Enfin, Stéphane Bortzmeyer s’en prend aux donneurs de leçon, les fameux « yakafokons » qui, la plupart du temps, se contentent « de proposer des process (règles bureaucratiques à suivre aveuglément, dans l'espoir d'éliminer l'humain et donc les erreurs humaines) ». Or, comme nous venons de le dire, tous les tests de la Terre ne peuvent pas anticiper à 100 % ce qui se passera lors d’un déploiement en production. Google en a récemment fait les frais.
Cet incident devrait aussi aller dans le sens de ceux qui vantent une approche multi-cloud : n'importe quel hébergeur peut rencontrer un problème grave, il faut donc assurer une redondance à travers l'un de ses concurrents pour réduire les problèmes potentiels. Mais là aussi, cela dépendra du budget prévu et de votre capacité à tolérer une panne. Des éléments à prendre en compte dans vos plans de continuité d'activité (PCA) et de reprise d'activité (PRA). Vous n'en avez pas ? C'est peut-être l'occasion de vous y mettre.
Pour OVHcloud, le problème c’est l’image de marque
Pour OVHcloud, l'essentiel était de régler rapidement le problème et de passer à autre chose, d'où cette publication le jour même. Car le timing est malheureux : l'entreprise doit entrer en bourse à la fin de la semaine et nul doute que la société se serait bien passé de faire les gros titres avec cet incident, qui renvoie certains aux souvenirs de l’incendie du mois de mars. Un accident bien plus grave, qui avait provoqué de gros dégâts avec des données définitivement perdues pour ceux qui n’avaient pas mis en place de procédure de sauvegarde.
Commentaires (41)
#1
Une heure de black-out c’est relativement peu au final, et la communication d’Oles est toujours très rapide, et riche en détails techniques, en toute transparence. Je préfère ça à du bla bla marketing du genre “nos équipes travaillent à rétablir le service”. Par contre cette communication devrait être faite par une équipe, sur un compte Twitter dédié, pas juste par le CEO sur son compte perso…
#2
J’ai bien lu dans l’article que la panne était différente de celle de Facebook (interne à l’AS v.s. externe). Cependant, sa nature est est identique. La loi des séries ?
#2.1
Tout à fait, c’est même une série OVeHrkill.
#3
Peut être pas, l’argument donnée par OVH sur l’intensification des DDOS semble crédible (Microsoft vient également d’en subir un très gros) et pousse peut être les opérateur dans des mises à jour un peu précipité.
#4
Enfin que le site de suivi des incidents sois lui aussi tomber ne fait quand même pas très sérieux
#5
“Quand on vous dit de passer à IPv6”
Dit un site qui ne le supporte pas
#5.1
Tout est dit ici. Ne jamais mettre ses oeufs dans le même panier est une bonne pratique, tout comme il est essentiel de savoir quelle tolérance apporter à la panne versus les moyens qu’on se donne pour réduire le plus possible les risques.
Dans la pratique, hélas, le client va dire qu’il peut se permettre d’avoir X heures d’indisponibilité parce que sinon c’est trop cher, mais en cas de crash il faut remonter dans la seconde sinon c’est un scandale. Confère un meme qui tourne régulièrement dans les réseaux spécialisés avec le pot d’argent quasi vide puis quasi plein et comme légende : “security budget before a data breach / security budget after a data breach” (et sa variante avec un troisième pot largement plus gros : “data breach cost”).
Et vous avez bien fait de rappeler que plusieurs des gros acteurs ont eu des problèmes ces derniers temps. L’effet de loupe arrive vite à la moindre défaillance d’un hébergeur et on oublie à côté que la fiabilité est globalement très bonne et que personne n’est à l’abri d’un problème. Pour faire une métaphore, c’est comme le crash d’un avion. C’est extrêmement rare, mais sur-médiatisé lorsque ça arrive, ce qui a tendance à biaiser l’opinion alors que c’est un moyen de transport pourtant très sûr.
Shit happens comme on dit.
Ca ressemble pas à une IPV4 ce que je vois en résultat.
#5.2
My bad j’aurais du vérifié il y a encore quelque mois il le supportait pas.
#5.3
ça fait pourtant plus d’un an au moins que le site est dispo en IPv6
#5.4
Hum, je me trompe peut-être, mais www.nextinpact.com (note les www) semble ne pas avoir d’IPv6.
#5.6
Pas tout à fait :
mais effectivement
et inpact-hardware ne répond jamais en v6
#5.7
Comme on a déjà répondu sur le sujet, on est en attente d’une évolution technique de Scaleway à ce sujet
#5.5
Ah oui bien vu, quel scandale !
#6
Passer au multi-cloud n’est pas qu’un problème de budget. Le faire revient à se restreindre au plus petit dénominateur commun entre les fournisseurs. On se prive alors du bénéfice des milliard de dollars/euros investis annuellement dans la R&D par les hyperscalers.
De plus, le multi-cloud augmente la complexité des déploiements. Et l’expérience montre que plus de complexité va de pair avec moins de disponibilité et moins de sécurité.
#7
D’ailleurs concrètement, que veut dire “passer à l’IPv6”, au-delà de ne plus la bloquer de partout ? Pourquoi est-ce qu’on peut la bloquer d’ailleurs ?
#7.1
Parce que:
Ce n’est pas compris dans les firmwares des routeurs chinois à deux balles que nous mettent à disposition les FAI dans certains pays, donc un coût énorme de les reprogrammer ou remplacer.
La flemme des techniciens d’apprendre (je parle des sociétés là, pas des FAI), et les former coûte cher.
C’est une deuxième couche à prendre en compte dans la sécurité (pare-feu, etc.), donc tout reconfigurer.
En résumé, ça coûte cher de passer à l’IPv6.
#7.2
D’accord, je pensais que tout ça était en place depuis longtemps et qu’il ne tenait qu’à l’utilisateur de l’activer ou pas (en l’occurrence ici pour qu’une panne IPv4 passe inaperçue).
#8
Bah enfaite oui, car sur des machine pro, il existe des système intégré qui détecte les ip malicieuse, hors ces liste n’existe pas (ou sont très peu utilisée car les ipv6 sont souvent en dure dans les malware donc beaucoup d’entreprise désactive juste “dhcpv6 et RA ou prefix delegation”
#9
Je ne suis pas sûr d’avoir compris pourquoi l’incident à duré moins longtemps en IPv6 qu’en IPv4 (7 minutes vs 1h) et pourquoi il aurait été moins grave en cas de généralisation du premier ?
#10
Yakafokon, mais s’assurer d’avoir un rollback écrit et qui fonctionne avant de démarrer c’est assez recommandé
#10.1
Vu ce qui est décrit dans l’article, tu suggères quoi comme rollback différent de ce qu’ils ont fait (et d’ailleurs, vu la description des pannes, je trouve qu’ils ont été plutôt rapides) ?
#10.2
Bah justement. Ils avaient une procédure, qui fonctionnait, mais pas de bol sur un copier-coller.
Nulle part il était écrit qu’il n’y avait pas de procédure de rollback. Il y en avait sûrement une, qui a peut-être été exécutée, ou pas, car ils ont considéré que c’était plus problématique que de corriger le problème…
Quand ta REL dure 4 heures et ton rollback 8h, tu réfléchis avant de rollbacker en cas de problème…
Et parfois, on ne peut pas rollbacker…
C’est toujours une question de balance gain/coût/risque.
#11
C’est pas la bloquer, c’est plutôt la supporter, et sur toute la chaîne du réseau. L’IPv6 est totalement incompatible avec l’IPv4 même si ma ressemblance du nom peut être trompeuse, ça revient donc à construire un deuxième réseau parallèle au premier, en dupliquant les équipements (soit matériellement, soit logiciellement) et les configurations.
C’est donc plus ou moins le même boulot que monter un réseau IPv4, le câblage en moins.
#12
C’est pour ça que certains l’hébergent chez un concurrent, pour qu’il reste accessible même en cas de soucis interne.
#13
C’est un concours de circonstances.
Au moment de mettre les nouvelles règles dans le routeur ils ont d’abord mis les règles ipv6, puis celles de ipv4, sauf qu’en collant celles de ipv4, le caractère 4 c’est retrouvé a la ligne, donc le routeur fonctionnait en ipv6, mais n’avait pas de règles pour ipv4.
Donc ce cas la ipv6 aurait servi de roue de secours a internet. De la même manière que si l’erreur était arrivé sur la config ipv6, ipv4 aurait servi de backup.
#14
Tout cela vient d’un copié coller mal passé. Ca me rappelle une gourde que j’avais commise chez un hébergeur où j’avais oublié d’ajouté “add” à la ligne d’ajout de vlan. Du coup, j’avais supprimé la quasi totalité des vlans sur un port trunk dans le DC… Autant dire que j’avais flingué les clients.
J’ai transpiré et me suis fait virer dans l’heure qui a suivie mais ce que je comprends c’est surtout que même si une opération est bien prévue (j’avais bien revu les commandes avant de les taper) il reste toujours une possibilité de foirer.
Vous dites qu’une heure c’est pas grand chose mais pour un site e-commerce, c’est énorme en fait. ce qui est d’ailleurs le plus important c’est les leçons que va tirer OVH de cet incident. Car dans mon ancienne boite, j’ai pas eu l’impression qu’en dehors de la panne, ils avaient fait une vraie remise en cause des process à mettre en place pour éviter ça.
Ils se sont rendus compte que les onduleurs n’étaient pas joignables pour couper la prise liée au routeur afin de relancer la dernière bonne configuration. L’accompagnement dans l’opération n’avait pas été présente suffisamment etc…
#14.1
Shit happens comme on dit.
Après, en France, te virer pour une erreur, ils perdent aux prudhommes..
Le problème n’est pas 1h c’est beaucoup ou pas assez, le problème c’est que si c’est dans le contrat, ben faut pas pleurer ^^; Si c’est hors contrat, on peut pleurer, avoir compensation (avec avocats…) dans une limite imbitable mais c’est tout. Shit happens…
#15
Comme dit dans l’article, si ton activité est vitale au point de ne pas tolérer une panne d’une heure, la leçon à tirer c’est de revoir ton infrastructure si elle ne repose que sur un hébergeur (OVHcloud ou pas). Les PRA/PCA sont d’ailleurs là pour ça.
#15.1
Faire du multi cloud ça coûte cher (pas qu’en hébergement, surtout en temps humain), tu peux très bien avoir une activité pour laquelle c’est hyper complexe de mettre en place de genre d’infras tout en ayant besoin d’une bonne disponibilité pour assurer ton fonctionnement.
Est-ce que tu claquerais 120000€ de salaire annuel pour payer un mec à essayer de faire une infra aux petits oignons (qui ne sera jamais parfaite, entendons nous bien là dessus) pour un problème qui te fera perdre 20 000 euros ? Non. Est-ce que ça te fait quand même chier d’avoir perdu 20000€ de CA ? Oui probablement.
#15.2
Ben c’est exactement la réflexion proposée par David et l’article. Si ton activité est critique et que tu n’es pas en capacité de tolérer une heure de panne, tu mets les moyens derrière. Le multicloud est une possibilité, mais il peut y en avoir d’autre dépendant de comment l’activité est organisée. C’est là tout le travaille que l’architecture doit produire.
Si tu estimes que les moyens permettant d’assurer la haute disponibilité sont trop chers par rapport à la perte d’une heure d’activité, tu mets de l’eau dans ton vin et tolère celle-ci quand elle arrive (et se défouler sur le prestataire ne sert à rien dans ce cas là, sauf que c’est, hélas, le premier réflexe de la plupart des clients).
#15.3
Une infra c’est des choix, il n’y en a jamais de parfait. Mais ce genre de dispositif c’est comme la sauvegarde ou les assurances. On peut vivre sans et regretter de devoir payer de temps en temps pour un petit problème. Le jour où la maison s’écroule pour une raison où un autre, on est quand même content de l’avoir.
#16
99,99% de disponibilité ça fait 0.87h de downtime par an, soit 52 minutes, pas 3 jours et demi haha
on en est déjà très loin là…
#16.1
Oui loin des 3 jours dans l’exemple.
En revanche chez OVH :
A voir ce qu’ils feront pour les public cloud, mais pour les “sites vitrines” ou les “sites de vente en ligne” qui sont hébergés sur du WebCloud a 50€/ans, je dirais qu’ils n’ont que ce qu’ils payent^^
#17
J’aime beaucoup Bortzmeyer, mais quand il dit : “l’ancienne version IPV4” ça me fait un peu tiquer
Quand on pourra faire de l’IP failover en IPV6 (chez OVH / SYS) on verra ensuite pour tout reconfigurer sur les serveurs
#18
Ce que je comprend pas c’est comment ils ont pas un “raspberry pi” dans chaque infra qui tente de joindre les autres afin de détecté ces soucis quasi immédiatement (si le gas ou la femme) qui avais fait l’erreur avais eu un retours négatif quasi instantané, l’erreur aurait coupé l’accès que quelques minutes max).
note: solution simpliste peut être impossible a réaliser a leur échelles.
#18.1
Si tu perds le lien, c’est qu’OSPF est déjà parti en vrille, donc il est déjà trop tard : tout ton réseau est planté.
#19
Le gars rentre chez lui : “Maman, j’ai coupé l’internet !”
Et dire qu’il y a encore des cons pour faire la chasse aux terroristes… ;)=
#20
Si l’erreur était arrivée sur la config ipv6, plus probablement la panne serait simplement restée indolore et la presse n’en aurait pas parlé.
#21
C’est tellement ridicule, arrogant et fallacieux d’appelé les gens “yakafokons”, genre leur avis ont aucune validité. OVH stack les erreurs, ce n’est pas sérieux a ce niveau, d’autant plus que ça tourne bien chez les concurrents…
#21.1
Les concurents genre Facebook? AWS? Azure? qui ont tous eu de bons problèmes (réseau ou autre) sur les 2 dernières années mais ont très peu communiquer dessus?
J’était tombé sur un un petit listing (via la FRNOG je crois, j’essaierai de le retrouver à l’occase), moi même j’était pas au courant de la moitié, pourtant il y a eu pas mal de monde d’impacté..
#22
Ce nom est certes péjoratif, mais il représente bien la situation.