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.
