Panne OVH : incident « clos » et premières explications techniques

« Incident clos ». Sur le site travaux.ovh.net destiné à informer les utilisateurs sur les pannes et dérangements touchant le service de OVH, l’hébergeur indique que la méga-panne qui a touché ses infrastructures ce jeudi matin est terminée. Rappelons que cet incident majeur a plongé dans le noir potentiellement plus de 3 millions de sites Web, dont des grands noms des médias, du e-commerce, de la banque… Cela ne veut pas dire que tous le sites dans le noir sont tous désormais en ligne mais du côté de l’hébergeur on indique que l’alimentation électrique fonctionne et que le datacenter est « up ».

Néanmoins, OVH constate encore cet après-midi des soucis dans la réception des emails pour ses clients. « La réception des messages est interrompue pour le moment. Les envois de message fonctionne normalement. La consultation des message à P19 fonctionne aussi mais la consultation des messages a GRA ne fonctionne pas pour le moment. Nous travaillons tous dessus ». Et d’ajouter un  peu plus tard : « Nous améliorons la configuration de nos serveurs afin de mieux gérer la charge. La réception est lente, aucun message ne sera perdu ».

 

La panne de grande ampleur est intervenue ce jeudi matin 7h dans le datacenter de Strasbourg (SBG) : « Nous avons un souci d’alimentation de SBG1/SBG4. Les 2 arrivées électriques EDF sont down (!!) et les 2 chaines de groupes électrogènes se sont mis en défaut (!!!). L’ensemble de 4 arrivées elec n’alimentent plus la salle de routage. Nous sommes tous sur le problème ».

Et d’ajouter un peu plus tard : « En plus de souci sur SBG [Strasbourg, NDLR], nous avons le souci sur le réseau optique en Europe qui interconnecte RBX [Roubaix, NDLR] et GRA [Gravelines, NDLR] avec les POP. Il est down (!!) ». 

Panne EDF et panne des groupes électrogènes (soit 4 sources d’énergie down), backbone en carafe, l’effet domino est fatal. Visiblement, les deux incidents ne sont pas liés.

Responsabilité assumée 

A 11h30, l’incident semblait en cours de résolution et de nombreuses entreprises ou sites Web touchés témoignent d’un certain retour à la normale, mais d’autres sont encore inaccessibles. Ainsi, un des liens EDF a été réparé et le datacenter de Strasbourg semble reprendre peu à peu vie. « Nous sommes sincèrement désolés. Nous venons de vivre 2 évènements simultanés et indépendants qui ont impactés tous les clients de RBX entre 8h15 et 10h37 et tous les clients de SBG entre 7h15 et 11h15. Nous continuons à travailler sur les clients qui ne sont pas encore UP à SBG ».

À 12h40, un rapport d’incident a été publié sur le site travaux.ovh.net destiné à informer les utilisateurs sur les pannes et dérangements touchant le service de OVH. Octave Klaba assure que les incidents sont en voie de résolution.

A Strasbourg : « L’alimentation a été rétablie et les services sont en cours de redémarrage. Certains clients sont UP et d’autres pas encore. Si votre service n’est pas encore UP, le délai de rétablissement est compris entre 5 minutes et 3-4 heures. Notre système de monitoring nous permet de savoir quel client est encore impacté et nous nous travaillons pour les fixer ».

A Roubaix : « Nous avons eu un problème sur le réseau optique qui permet à RBX d’être connecté avec les points d’interconnexion que nous avons à Paris, Francfort, Amsterdam, London, Bruxelles. L’origine du problème est un bug software sur les équipements optiques qui a provoqué la perte de la configuration et la coupure de la connexion avec notre site de RBX. Nous avons remis le backup de la configuration software dés que nous avons diagnostiqué l’origine du problème et le DC est à nouveau joignable. L’incident sur RBX est clos. Avec le constructeur, nous cherchons l’origine du bug software et aussi comment ne plus subir ce genre d’incident critique ». 

Dans un nouveau billet, Octave Klaba revient en détails sur la méga-panne qui aurait selon l’hébergeur duré au total 2 heures et 33 minutes. Et assume la responsabilité de l’hébergeur.

« Ce matin, nous avons eu un incident sur le réseau optique qui interconnecte notre site de Roubaix (RBX) avec 6 des 33 points de présence (POP) de notre réseau : Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU). Le site RBX est connecté à travers 6 fibres optiques à ces 6 POP : 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Ces 6 fibres optiques sont connectées aux systèmes de nœuds optiques qui permettent d’avoir 80 longueurs d’onde de 100Gbps sur chaque fibre optique.

Pour chaque 100G connectés aux routeurs, nous utilisons 2 chemins optiques qui sont géographiquement distincts. En cas de coupure de fibre optique, le fameux « coup de pelleteuse », le système se reconfigure en 50ms et tous les liens restent UP. Pour connecter RBX aux POP, nous avons 4.4Tbps de capacité, 44x100G : 12x 100G vers Paris, 8x100G vers London, 2x100G vers Bruxelles, 8x100G vers Amsterdam, 10x100G vers Frankfurt, 2x100G vers DC GRA et 2x100G vers DC SBG.

A 8h01, d’un coup, l’ensemble des liens 100G, les 44x 100G, ont été perdus. Étant donné le système de redondance que nous avons mis en place, l’origine du problème ne pouvait pas être la coupure physique de 6 fibres optiques simultanément. Nous n’avons pas pu faire les diagnostiques sur les châssis à distance car les interfaces de management étaient figées. Nous avons été obligés d’intervenir directement dans les salles de routage, pour faire les manipulations sur les châssis : déconnecter les câbles entre les châssis puis faire redémarrer le système et enfin seulement faire les diagnostiques avec l’équipementier. Les tentatives de redémarrage du système ont pris beaucoup de temps, car chaque châssis a besoin de 10 à 12 minutes pour démarrer. C’est la principale raison de la durée de l’incident.

Le diagnostique : Toutes les cartes transpondeurs que nous utilisons, ncs2k-400g-lk9, ncs2k-200g-cklc, sont passées en état « standby ». L’une des origines possible d’un tel état est la perte de configuration. Nous avons donc récupéré le backup et remis en place la configuration, ce qui a permis au système de reconfigurer toutes les cartes transpondeurs. Les 100G dans les routeurs sont revenus naturellement et la connexion de RBX vers les 6 POP a été rétablie à 10h34.

Il s’agit clairement d’un bug software sur les équipements optiques. La base de données avec la configuration est enregistrée 3 fois et copiée sur 2 cartes de supervision. Malgré toutes ces sécurités, la base a disparu. Nous allons travailler avec l’équipementier pour trouver l’origine du problème et les aider à fixer le bug. Nous ne remettons pas en cause la confiance avec l’équipementier, même si ce type de bug est particulièrement critique. L’uptime est une question de design qui prend en compte tous les cas de figure, y compris quand plus rien ne marche. Le mode parano chez Ovh doit être poussé encore plus loin dans l’ensemble de nos designs.

Les bugs ça peut exister, les incidents qui impactent nos clients non. Il y a forcement une erreur chez Ovh puisque malgré tous les investissements dans le réseau, dans les fibres, dans les technologies, nous venons d’avoir 2 heures de downtime sur l’ensemble de nos infrastructures à Roubaix. 

L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs. 

Dans le métier de fournisseur des infrastructures Cloud, seul ceux qui sont paranos durent. La qualité de service est une conséquence de 2 éléments. Tous les incidents anticipés « by design ». Et les incidents où nous avons appris de nos erreurs. Cet incident là nous amène à mettre la barre encore plus haut pour s’approcher du risque zéro. 

Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA ». 

ZDNet