(modifié le 14 novembre 2017 à 9:12)

Quand une panne fait autant parler d'elle c'est qu'elle touche trop de monde. Et cette journée du 09 Novembre 2017 restera dans l'histoire d'OVH comme une des pires journées.

https://twitter.com/xhark/status/928536627248582656

Jamais une panne de cette ampleur ne s'était produite et c'est Octave qui nous résume cet incident majeur.Bref, la loi de Murphy a encore frappé...

Comme a son habitude Octave nous offre tous les détails techniques et avoir autant de transparence est loin d'être la règle dans le domaine de l'hébergement.

Bonjour,
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.

Amicalement
Octave

Après avoir lu ces détails techniques on comprend un peu mieux ce qu'il s'est passé. Pour faire simple tout le backbone OVH était en vrac. Comme quoi avoir des datacenters un peu partout ne solutionne pas tout, il faut aussi penser au backbone même quand les liens fibres sont redondés. Avec un seul système de noeud qui perd sa configuration et tout s'effondre.

Octave évoque un potentiel bug de firmware, personnellement je trouve cela étrange quand il dit que toutes les cartes transpondeur sont passées en standby alors même que la base est enregistrée 3 fois et clonée sur 2 bases de supervision. Je ne me prononcerai pas car on parle là d'équipement très spécifiques mais que tout plante d'un coup d'un seul et qu'aucun mécanisme de protection protège les autres équipements... même avec un bug j'ai du mal à accepter cette hypothèse.

Espérons tout de même que ce soit un bug plutôt qu'un sabotage. La pagaille chez OVH a du être d'une ampleur indescriptible ce matin, les consoles de supervision bien colorées et les échanges tendus.

Il y a beaucoup d'enseignements à tirer de cette histoire, sur le plan technique mais pas que. Héberger la page de statut avec un repli chez un autre hébergeur ne me paraît pas déconnant... heureusement que twitter était là pour assurer la communication, au milieu des tweets humoristiques :

https://twitter.com/ThomasPhilibert/status/928533558553178112

Espérons aussi que cela fasse évoluer aussi un peu la vision de certaines entreprises (DSI) sur le cloud. Car oui, même les meilleurs rencontrent des pépins, OVH n'est ni le premier ni le dernier. Office365, Google, etc... tout le monde connaît à un moment donné un coup de calgon. Les machines sont créées et pilotées par le humains, le risque zéro n'existe pas.

https://twitter.com/olesovhcom/status/929648118240612352

Et puis après tout il est vrai que l'élément déclencheur est la rupture d'alimentation électrique, pour laquelle OVH ne pouvait pas faire grand chose. Ajoutez à cela la loi de Murphy, mélangez et vous obtenez un sacré bordel (mais on a vu personne de chez ovh sur le canal 911 du discord ^^).

https://twitter.com/olesovhcom/status/929648836091482112

Les conséquences de cette coupure risquent d'être importantes : dédommagements, plaintes, etc. Les assurances des protagonistes ont du boulot sur la planche.

https://twitter.com/olesovhcom/status/929654854267625472

L'incident concernant l'électricité est détaillé ici par Octave.