Retour d’expérience sur l’incident réseau du 9/11/2017 sur le site de Roubaix

Temps de lecture estimé : 19 minute(s)

Comme nous l’avons déjà exprimé, notre métier de fournisseur d’infrastructure cloud consiste à anticiper tout type de scénarios, et à imaginer puis déployer les dispositifs de sécurisation nécessaires pour garantir la continuité de service en toutes circonstances. De la défaillance hardware ou software d’un équipement au coup de pelleteuse malencontreux sectionnant un fourreau de fibres, en passant par les erreurs humaines. L’incident réseau survenu le 9 novembre dernier sur le site de Roubaix nous rappelle que la réalité dépasse parfois l’imagination, révélant le cas improbable auquel nous n’avions pas pensé, l’invraisemblable cascade de bugs à laquelle personne n’avait encore été confronté.

Pourquoi un retour d’expérience ?

Lorsque ce type d’événement survient, notre priorité est d’établir le bon diagnostic et de rétablir le service dans les plus brefs délais. Puis, dès l’incident clos, il faut remettre en question les choix techniques, les certitudes d’hier pourtant fondées sur des années de pratique. Notre mission consiste alors à concevoir un système encore plus tolérant à la défaillance d’un ou de plusieurs éléments en cascade. Et c’est probablement là que notre métier prend toute sa valeur, chaque incident survenu ayant pour conséquence positive de rendre nos infrastructures plus robustes, nos procédures plus fiables, nos diagnostics plus rapides et précis. Les incidents dont on ne parle pas, mais font pourtant partie du quotidien d’un cloud provider (en témoigne le site travaux.ovh.net), permettent quant à eux d’éprouver et perfectionner chaque jour les mécanismes de sécurité mis en place.

Une semaine après, nous avons souhaité revenir plus en détail sur le déroulé de l’incident réseau du 9 novembre 2017 sur le site de Roubaix, en éclaircissant à la fois la nature et le rôle des équipements qui ont fait défaut, ainsi que les plans d’action à court et moyen termes que nous avons déclenchés – et d’ores et déjà partiellement mis en œuvre – pour prévenir la reproduction d’une telle situation. Au-delà de la volonté d’être totalement transparents, ce qui nous semble essentiel dans le cadre de la relation de confiance qui nous lie à nos clients, nous pensons que ce retour d’expérience peut profiter à tous. À ceux qui seront un jour ou l’autre confrontés à ce type de situation, y compris à une plus petite échelle, et à ceux qui s’intéressent à la complexité des infrastructures sur lesquelles s’appuie le réseau Internet.

La promesse du Cloud est de simplifier l’IT. En réalité, la complexité ne disparaît pas. Elle est simplement transférée à des cloud providers tels qu’OVH, dont le métier est méconnu du grand public, mais dont le rôle est de plus en plus stratégique. En centralisant ainsi les infrastructures, les cloud providers ont, de par l’échelle à laquelle ils opèrent, les moyens d’offrir à leurs clients des protections robustes contre les attaques DDoS, une bande passante de qualité et des latences faibles depuis n’importe quel endroit du monde, une redondance électrique et réseau… Tout ceci à un coût en général plus faible que si les machines étaient hébergées par les entreprises elles-mêmes. La contrepartie est que les cloud providers héritent d’une grande responsabilité : garantir la disponibilité sans faille des services. Sans quoi, comme ce fut le cas le 9 novembre, ils se retrouvent à juste titre sous le feu des projecteurs.

Le rôle d’un nœud optique

Revenons à l’incident lui-même. Mais avant cela, il est nécessaire de planter le décor, et d’évoquer le rôle du système optique en cause. Le site de Roubaix (RBX), sur lequel se situe le siège social de l’entreprise, comporte 7 datacenters distincts. Comme les 11 autres sites du groupe, Roubaix est connecté au réseau mondial d’OVH (et donc au réseau Internet) via plusieurs « pénétrantes ». C’est-à-dire des fibres reliant le site à différents points de présence (PoP) du réseau mondial d’OVH, via des tracés géographiquement distincts. En l’occurrence, le site de Roubaix est connecté directement à 6 des 33 PoP du backbone d’OVH : Paris (via TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU).

Dans le détail, il s’agit de 6 fibres optiques : 2x RBX<>BRU, 1x RBX<>LDN, 1x RBX<>GRA, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Dès lors que la distance excède 80 kilomètres, le lien fibré est entrecoupé de sites d’amplification pour pallier l’atténuation naturelle du signal.

Ces 6 fibres sont physiquement rassemblées, sur le site de Roubaix, au sein d’un système que l’on nomme « nœud optique ».  Le rôle de ce nœud optique, aussi appelé équipement de multiplexage optique, est notamment de créer sur les fibres des longueurs d’onde. Si l’on se réfère au modèle OSI qui explicite les différentes couches de la communication entre systèmes informatiques, il s’agit de créer des circuits cohérents de niveau 1 (OTU4 pour 112 Gbps) en diversifiant les chemins optiques, afin de disposer d’un backbone doté de circuits de niveau 2 (Ethernet 100 Gbps) sécurisés. Une fibre peut contenir jusqu’à 80 longueurs d’onde, d’une capacité de 100 Gbps chacune.

Le système de nœud optique est composé à Roubaix d’une vingtaine de châssis, répartis en deux catégories.

La première catégorie de châssis est équipée de 2 cartes de supervision (TNC), respectivement placées en slots 1 et 8 (carte du haut et du bas sur les photos ci-dessous) et d’un LCD (carte intégrée du châssis). Le milieu du châssis est occupé par des amplificateurs et des cartes ROADM, sur les 6 slots restants. Il y a un châssis de ce type par direction : vers BRU, vers LDN, vers GWS (Paris), vers TH2 (Paris) et vers GRA. La fibre a toujours une direction, par exemple RBX<>TH2 va physiquement vers TH2. Mais, sur ces liens physiques, nous créons des circuits logiques, qui permettent par exemple de relier RBX à SBG en passant par le PoP parisien de TH2. On parle alors d’une route.

Principe de fonctionnement du nœud optique du site de Roubaix (en imaginant N châssis de la seconde catégorie, comportant carte de protection optique et transpondeur).

La seconde catégorie de châssis est constituée d’une carte PSM (carte de protection optique) et d’une carte TXP (carte transpondeur). Cette dernière carte est directement connectée aux routeurs en aval, et convertit le signal optique en signal qu’un routeur peut interpréter. La carte de protection optique permet quant à elle de basculer du chemin nominal au chemin de protection et de reconfigurer le système en moins de 50 ms, en cas de coupure de fibre. Car chaque lien 100 Gbps est protégé par un chemin alternatif, inutilisé en temps normal et empruntant une fibre distincte. Par exemple, le circuit nominal de RBX<>GRA emprunte la fibre directe RBX-GRA, et le chemin de protection emprunte la route RBX<>BRU<>GRA car nous avons une fibre entre RBX<>BRU et GRA<>BRU.

Principe de fonctionnement de la protection optique.

Il faut savoir que le fameux « coup de pelleteuse » constitue le risque n°1 en matière de réseau. Notez qu’il est moins redouté dans certains pays comme les États-Unis ou le Canada, car les installations fibrées y sont en partie aériennes. Elles sont, de ce fait, plus sensibles à l’arrachage ou aux événements climatiques… C’est pourquoi les réseaux sont toujours sécurisés par la diversification géographique des chemins fibrés, de sorte à ce qu’il y ait toujours des liens disponibles, par lesquels écouler le trafic.

Le système de nœud optique est réparti au sein des deux salles réseau jumelles du site de Roubaix. Ces deux salles réseau sont strictement identiques, mais physiquement situées au sein de deux datacenters distincts, et sont donc rattachées à deux domaines de panne électrique. Les équipements de ces salles travaillent de concert en temps normal pour router le trafic du site. Ces salles sont capables de prendre le relais l’une de l’autre de façon totalement automatique et transparente en cas d’incident affectant l’une d’elle.

Vous l’aurez compris, le système de nœud optique est un système critique, de par son rôle essentiel dans la connexion du site vers le reste du backbone OVH et donc du réseau Internet. Aussi, ce système s’appuie sur une technologie « rockstable » comme on dit dans le métier, aussi bien au niveau du hardware que du software, et bénéficie d’une double alimentation électrique. Les composants physiques essentiels comme les cartes de supervision sont redondés, et le système continue à fonctionner normalement en cas de perte d’un ou plusieurs châssis, y compris celui qui joue le rôle du master dans le cluster (c’est-à-dire celui qui provisionne et monitore les châssis esclaves). Autrement dit, le risque que ce système tombe est quasiment nul. Du moins, c’est ce dont nous étions persuadés.

Zoom sur 3 des 20 châssis du nœud optique du site de Roubaix.

La complexité du diagnostic

Le 9 novembre à 8 h 01 précisément, nos systèmes détectent la perte soudaine et simultanée de l’ensemble des 50 liens 100 Gbps connectant le site RBX au reste du monde (en réalité, il s’agit de 50 liens x 2 puisque chaque lien est protégé par un second lien empruntant une route physique différente). Étant donné les systèmes de redondance décrits plus haut, il est impossible que l’origine du problème soit une coupure physique des 6 fibres optiques. Même le plus diabolique des chefs de chantier ne serait pas parvenu à une coordination si parfaite des pelleteuses en activité dans le nord de l’Europe.

L’équipe réseau est immédiatement alertée et tente, dès 8 h 15, de se connecter à distance au système de nœud optique, après avoir rapidement écarté d’autres pistes étant donné l’ampleur du dysfonctionnement. En vain, car les interfaces de management du système sont figées.

Comme évoqué plus haut, les 20 châssis du système de nœud optique fonctionnent en cluster, sous la supervision d’un « node controller » (l’un des châssis, désigné comme maître). Ce nœud maître assure la synchronisation des informations entre l’ensemble des châssis, mais dialogue également avec l’ensemble des autres nœuds optiques du réseau OVH, situés dans 14 PoP du réseau ainsi que sur chacun des 12 sites. Ce réseau de management permet de déployer et de garantir la cohérence du niveau 1 de notre réseau (le modèle OSI, souvenez-vous).

Bugs en cascade

Nous aurons l’explication par la suite, grâce au diagnostic approfondi effectué avec l’aide de l’équipementier : en raison d’une charge CPU anormalement élevée, qui a débuté à 7 h 50, soit 10 minutes avant la perte des liens, un bug software connu du constructeur s’est déclaré. Sur les nœuds de taille importante, celui-ci a pour conséquence de faire un switchover des cartes de supervision du châssis toutes les 30 secondes. En clair : la carte de supervision TNC est doublée sur chacun des châssis, pour parer une panne hardware, les deux cartes fonctionnant en mode actif/passif. Le switchover entraîné par le bug a consisté à ce que les deux cartes du node controller soient, alternativement considérées, toutes les 30 secondes, comme active, puis passive, puis active, puis passive… ce flapping occasionnant l’impossibilité de reprendre le contrôle du châssis via le système de management. En temps normal ce switchover se stabilise seul. Ce ne fut pas le cas.

Zoom sur le node controller du nœud optique de RBX.

À 9 h 00, les équipes sont dans les salles hébergeant le nœud optique et la décision est prise de redémarrer électriquement le châssis maître. Le temps de redémarrage d’un tel équipement est compris entre 10 et 12 minutes. À 9 h 15, nous constatons que le redémarrage ne nous permet pas de reprendre la main sur le système de management, en raison d’une très forte charge CPU. Pour réduire cette charge, nous déconnectons les câbles qui permettent au système de dialoguer avec les autres nœuds optiques d’OVH. La charge CPU baisse et nous parvenons à reprendre la main sur le châssis maître à 9 h 30.

Nous constatons que tous les châssis du nœud optique de RBX sont à nouveau visibles par le système de management. Mais aucune alerte n’apparaît, or les liens ne fonctionnement toujours pas.

Nous apprendrons plus tard qu’à la suite du premier bug, le switchover des cartes de supervision du châssis maître, la configuration du nœud a été perdue. Ou plutôt que le châssis maître a propagé la consigne aux nœuds esclaves de réinitialiser leur configuration en mettant la base de données à zéro, à la suite d’une désynchronisation entre les deux cartes de supervision du châssis maître.

La perte de la configuration du nœud est un diagnostic que nous avons mis du temps à effectuer, car c’est, en théorie, absolument impossible. Et pour cause : la database est contenue, localement, sur chacun des châssis du nœud optique, sur chacune des deux cartes de supervision. Pour cette raison, le système est tolérant à la panne du node controller lui-même. Et c’est aussi pour cette raison que la surcharge CPU du node controller n’est pas un soi un événement alarmant : elle est naturelle lorsque des opérations d’écriture sont en cours, et n’empêche pas le système de fonctionner correctement.

Ici, l’incident s’explique donc par une cascade de bugs, chacun étant totalement distinct des autres, mais ayant probablement constitué un élément déclencheur (trigger) pour les autres.

À 10 h 00, nous comprenons que la configuration du nœud a été perdue, après avoir été trompés par l’affichage sur l’écran LCD de l’équipement, lequel affichait correctement l’adresse IP où il était censé être joignable. Le backup de cette base de données est dupliqué sur plusieurs sites distants. Nous récupérons la sauvegarde stockée sur le site de Gravelines et réinjectons ce backup dans le système. Les liens commencent à remonter à partir de 10 h 15.

À 10 h 30, 8 des 50 liens sont encore down, mais cela est sans incidence sur le trafic : le site de Roubaix est à nouveau accessible, les services des clients redeviennent fonctionnels quasi instantanément. L’indisponibilité aura duré 2 h 30.

À 11 h 00, nous constatons que certains transpondeurs ne sont pas vus par le système, et un amplificateur est HS. On lance le RMA de l’équipement endommagé.

À 11 h 30, certains transpondeurs sont fonctionnels, mais ne sont pas visibles dans le système. Ils sont redémarrés. Tous les circuits sont remontés. À 14 h 15 les composants endommagés de l’amplificateur, reçus dans l’intervalle, sont remplacés. Cela nous permet de disposer à nouveau de l’intégralité des protections et redondances du système, qui fonctionne normalement depuis 10 h 30.

Les enseignements et les premières actions préventives

L’incident nous a appris plusieurs choses. La première est que la charge CPU élevée sur le node controller doit être surveillée et évitée, en raison des bugs qu’elle a occasionnés. Par précaution, nous avions prévu de remplacer les cartes de supervision (TNCE) de nos plus gros nœuds optiques par des cartes de puissance supérieure.

Il s’agissait d’un upgrade non critique, mais celui-ci était planifié avant la fin de l’année. De ce fait, nous avions reçu récemment 4 cartes TNCS, deux fois plus puissantes en CPU et dotées du double du RAM. Nous avons accéléré le remplacement des cartes des nodes controllers de Roubaix et Gravelines, où se trouvent à ce jour les plus importants nœuds optiques, en termes de nombre de châssis (ce nombre étant le principal facteur de charge CPU sur le node controller). Ces remplacements des cartes de supervision ont été réalisés dans la nuit du 13 au 14 novembre et dans la nuit suivante. Une opération transparente (sans interruption de service) puisque le swap est réalisé à chaud. Nous avons également programmé le remplacement des cartes de supervision des châssis maître des nœuds optiques de Strasbourg et Francfort.

De cette façon, nous écartons une première cause de dysfonctionnement et cela permet d’avoir une marge conséquente sur les ressources disponibles, pour prévenir l’inaccessibilité du système de management. Néanmoins, nous devons aussi remettre en question la confiance que nous avons eu dans la fiabilité absolue du système de management, et trouver un moyen de l’outrepasser en cas de nécessité. En informatique, et plus encore lorsque l’on opère à notre échelle massive et mondiale, il ne peut y avoir de confiance absolue dans un système ou un équipement.

La seconde action est la mise à jour software des équipements. Le second bug (remise à zéro de la base de données propagée à l’ensemble des châssis esclaves suite à la désynchronisation des deux cartes de supervision du châssis maître) a été fixé dans la release 10.7, que nous avons déployée la semaine du 13 novembre. Le premier bug, en revanche (flapping des cartes de supervision suite à la surcharge CPU) sera corrigé dans la release 10.8, dont l’ETA est fixé par le constructeur début décembre. Nous avons naturellement travaillé main dans la main avec l’équipementier, et toutes les informations nécessaires lui ont été remontées afin que les bugs et leurs conditions d’apparition soient étudiés dans le détail. Il faut aussi noter la qualité du support de cet équipementier, qui a rapidement mis à notre disposition toutes les ressources nécessaires à l’analyse du problème, y compris durant le week-end suivant l’incident pour nous accompagner dans l’élaboration du plan d’action à court terme.

Une précision : on peut légitimement se demander s’il n’aurait pas été plus prudent de faire les mises à jour software dès leur sortie. Vous l’avez compris, les équipements dont il est question sont critiques. Aussi, sur ce type d’équipement, une mise à jour software comporte des risques non négligeables. Les releases corrigent évidemment des bugs, mais ajoutent aussi de nouvelles fonctionnalités, ou le support de nouveaux hardwares. Le risque qu’une mise à jour contienne des bugs nouveaux n’est donc pas négligeable. Suivant notre politique interne et les recommandations du constructeur, les mises à jour ne sont pas appliquées systématiquement sur ce type d’équipements, sauf nécessité absolue (par exemple, des mises à jour relatives à la sécurité ou le support de nouveaux composants hardware, cartes ou optiques. C’est d’ailleurs pour cette raison que nous avions prévu de réaliser la mise à jour de ces équipements entre novembre 2017 et février 2018 : pour supporter de nouvelles cartes 400 Gbps et de nouvelles optiques 100 Gbps courte distance). Enfin, il faut souligner le niveau de confiance que nous avons dans ce matériel : nous utilisons ces technologies optiques depuis 2015, sans aucun incident ayant eu un impact sur nos clients. Pas regret de ce côté-là.

En revanche, et c’est ainsi qu’il faut comprendre le fait de devenir encore plus paranoïaque, nous devons maintenant concevoir qu’un tel scénario – la perte de l’ensemble d’un nœud optique – est probable, puisqu’il a eu lieu. L’équipe réseau a donc planché sur plusieurs options pour réduire le domaine de panne dans ce type de situation.

Le plan à court terme est de réaliser un split des systèmes de nœuds optiques par direction. Le risque de voir une configuration erronée se propager à l’ensemble du système en raison d’un bug sera ainsi endigué, puisque chaque partie du nœud ne discuterait qu’avec son homologue sur le site distant, qu’il s’agisse d’un PoP ou d’un site OVH comportant des datacenters. En cas d’incident, le domaine de panne est très circonscrit, et les autres directions restent fonctionnelles pour écouler le trafic.

Néanmoins, si le trafic nord-sud (serveurs <> Internet) a historiquement prédominé, une bascule s’opère aujourd’hui en faveur du trafic ouest-est (de serveur à serveur, entre nos différents sites, via le vRack). Nous devons prendre en compte cette évolution dans nos stratégies, ce qui pourrait, par exemple, nous conduire à envisager la construction de deux backbones parallèles et entièrement distinctes, chaque datacenter pouvant joindre chaque PoP en direct par l’un ou l’autre des réseaux.

Tout ceci sans perdre de vue que la sophistication des infrastructures peut devenir, à un certain niveau, un facteur de risque en elle-même, en complexifiant les déploiements, la maintenance et le management du réseau. Tout l’enjeu est donc de savoir où placer le curseur.

À l’heure qu’il est, la rédaction de l’ensemble des post-mortem se termine. Chaque équipe impliquée de près ou de loin, ou « simplement » affectée par l’incident a identifié ce qui a fonctionné, ce qui n’a fonctionné et ce qui doit être amélioré. Ceci en n’oubliant pas de discerner les facteurs chance et malchance qui souvent se combinent au cours d’un incident, compliquant le diagnostic ou au contraire facilitant finalement la résolution du dysfonctionnement. On dit qu’au-delà d’un certain niveau de complexité technique, le fonctionnement de tout équipement s’apparente à de la magie pour la plupart des humains. Si la magie d’Internet existe, rien de surnaturel chez OVH. Mais, parfois, des sacrés nœuds (optiques) à démêler.

Copywriter at OVH.