Panne géante d'OVH : l'opérateur de cloud paie des décisions d'architecture contestables

Les pannes massives qui ont affecté hier les datacenters de Roubaix et de Strasbourg résultent largement de l'absence de redondance sur des éléments critiques de l'infrastructure des datacenters du groupe. Le groupe s'est engagé à y remédier. Pour certains clients, le retour à la normale a été long et douloureux.

Jeudi 9 novembre, OVH a été affecté par une série de pannes majeures ses sites de Strasbourg (SBG) et Roubaix (RBX), des défaillances qui ont mis en lumière des choix de design pas forcément très heureux pour les datacenters du groupe et notamment l’absence de redondance sur des éléments critiques de son infrastructure.

Le principal incident a été causée par la rupture de l’alimentation électrique du datacenter de Strasbourg, à 7 h 23 le jeudi 9 novembre. Le second près d'une demi-heure plus tard a privé de connectivité le datacenter de Roubaix pendant une bonne partie de la matinée.

Panne électrique catastrophique à Strasbourg

Comme l’explique Octave Klaba, le datacenter d'OVH dans la capitale alsacienne est alimenté par « une ligne électrique de 20MVA composée de 2 câbles qui délivrent chacun 10MVA. Les 2 câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez l’entreprise locale de distribution d’électricité [Electricité de Strasbourg Réseaux, “l’Enedis local”, N.D.L.R]. Ce jeudi 9 novembre au matin, « l’un des 2 câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres ».

Octave Klaba, CEO et fondateur d'OVH, 
lors de l'OVH Summit à Paris

Le fait qu’un datacenter majeur ne soit desservi que par un unique poste d’alimentation moyenne tension - même si deux voies d’entrées sont mises en œuvre - est en soit un problème de conception, puisqu’une défaillance au niveau de ce poste se traduit par une rupture de l’alimentation du datacenter.Logiquement toutefois, la panne n’aurait pas dû avoir de conséquence, puisque le datacenter OVH de Strasbourg est équipé de groupes électrogènes supposés prendre le relais de l’alimentation principale en cas de défaillance. Mais c’est là que Murphy a pointé son vilain nez.

Comme l’explique Octave Klaba, « Le site SBG est prévu pour fonctionner, sans limites de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de 2 groupes de 2MVA chacun, configurés en N+1 et en 20KV. Pour SBG2, nous avons mis en place 3 groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont réalimentés en 20KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant 8 minutes. Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate ».

Résultat, une fois les réserves électriques des onduleurs épuisées, l’ensemble du datacenter a été privé d’alimentation, forçant à l’arrêt d’urgence des équipements télécoms et informatiques du datacenter. Un black-out qui s’est traduit par la panne d’un grand nombre de sites internet français mais aussi par l’indisponibilité des servcies de cloud public et privés utilisés par des milliers de clients du groupe.

Vers 10 h du matin, soit plus de 2 h 30 après la panne d’alimentation, OVH s’est décidé à relancer manuellement les groupes électrogènes et a travaillé avec ELD pour réalimenter l’un des câbles d’alimentation au réseau électrique. À 10 h 30 le site était de nouveau approvisionné en énergie et l’opérateur cloud commençait à relancer les équipements de télécommunication du site. À 10 h 58, les routeurs du site SBG étaient de nouveau opérationnels.

OVH était toutefois loin d’être au bout de ses efforts. Il a en effet fallu commencer à redémarrer les milliers de serveurs du datacenter. À 16 h près de 50 techniciens étaient à l’œuvre sur le site pour relancer progressivement les machines et équipements réseau de commutation et réparer ou remplacer ceux qui posaient problème (dont des cartes Fex sur des commutateurs Cisco Nexus - OVH utilise un mix de commutateurs Nexus 9000 et de commutateurs Arista dans ses infrastructures).

Une architecture électrique contestable qui va être remise à plat

De l’aveu même d’Octave Klaba, OVH paie les décisions de design prises lors de la construction du site, le seul basé sur l’empilement de conteneurs maritimes. Construit à base de conteneurs pleins de serveurs, SBG1 a été opérationnel en seulement 2 mois. Constatant que Strasbourg pouvait devenir une plaque stratégique pour son offre, OVH a ensuite construit un datacenter plus traditionnel en dur pour SBG2 en 2012. SBG4 en 2013 a renoué avec les conteneurs afin de répondre très rapidement à la croissance du groupe puis en 2016, OVH a lancé la construction de SBG3, lui aussi en dur.

Pour Octave Klaba, OVH a fait deux erreurs en déployant ses datacenters en conteneurs. Tout d’abord, « nous n’avons pas remis le site SBG aux normes internes qui prévoient 2 arrivées électriques indépendantes de 20KV, comme tous nos sites de DCs qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne ». Ensuite, « nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendants l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG ».

En réponse, à la panne géante de ce jeudi, OVH a validé un plan d’action correctif, qui va voir la firme investir 4 à 5 millions d’euros pour doubler l’alimentation du site avec une seconde entrée indépendante de 20MVA et qui va aussi se traduire par la séparation des réseaux électriques de SBG2 vis-à-vis de SBG1/SBG4, et du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4. Aussi rapidement que possible, les clients des datacenters conteneurisés de SBG1/SBG4 seront migrés vers le nouveau datacenter « en dur » SBG3 et les sites SBG1/SBG4 seront démantelés. 

Une panne majeure sur le réseau optique à Roubaix

Il était sans doute écrit que la journée du 9 novembre serait problématique pour OVH. Car alors que le datacenter de Strasbourg était victime d’un black-out, l’ensemble du réseau de transport optique desservant le site de Roubaix connaissait lui aussi un incident majeur. Comme l’explique Octave Klaba, Le site de Roubaix est connecté à travers 6 fibres optiques aux POP de Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), Londres (LDN) et Bruxelles (BRU). Chaque fibre supporte

80 longueurs d’onde en 100 Gigabit. Un peu après 8 h du matin, l’ensemble des connexions ont été perdues, une panne massive liée à une perte de configuration inexpliquée des équipements optiques Cisco NCS (Network Convergence System) utilisés par OVH, qui a mis l’ensemble des interfaces optiques DWDM en mode « standby ».

L’incident, lié vraisemblablement à un bug logiciel sur les équipements Cisco a contraint à un redémarrage complet des systèmes de transmission optique. Ce n’est finalement qu’à 10 h 34 que le site de Roubaix a retrouvé sa connectivité normale.

Pour éviter une panne équivalente à l’avenir, OVH prévoit de doubler le nombre de ses systèmes optiques afin d’ajouter plus de redondance à son infrastructure. Ces travaux étaient déjà en cours mais vont être accélérés. L’ensemble des sites de datacenter du groupe devrait d’ailleurs adopter des configurations similaires. Selon OVH, l’ensemble des clients impactés par la panne seront contactés pour déclencher l’application des engagements SLA.

Un redémarrage long et douloureux

Si OVH semble tirer les leçons de ces pannes, pour les clients le redémarrage s’avère plus long et douloureux que prévu. Ce vendredi matin à 1 h 30 du matin il restait ainsi 799 serveurs dédiés, 1150 instances de cloud public, 2400 serveurs privés virtuels et 200 serveurs hôtes de cloud privé en souffrance sur le site de Strasbourg. Deux heures plus tard, ces chiffres étaient encore respectivement de 710, 903, 2400 et 170.

Pour le service d’e-mail Exchange hébergé offert par OVH, la journée a aussi été longue puisque ce n’est que vers 22 h que le service a terminé de traiter son backlog d’e-mail et a pu revenir à la normale.

Certains services OVH étaient encore dégradés ce matin. Les services de stockage en mode bloc, affectés par la panne, voyaient ainsi leurs performances réduites du fait des opérations de « rebalancing » en cours. Là encore, il est vraisemblable que la situation ne devrait revenir pleinement à la normale que dans le courant de la journée de ce vendredi 10 novembre.

Pour approfondir sur Architectures de Datacenters

Close