Six choses qu'OVH ne dit pas sur l'incendie de Strasbourg

Conception des datacenters, architecture électrique et réseau, gestion des backups... Le point sur plusieurs informations clés qu'OVHCloud oublie d'évoquer dans sa communication de crise.

Suite à l'incendie qui s'est déclaré dans la nuit du 9 au 10 mars sur le campus alsacien d'OVHCloud, 3,6 millions de serveurs web représentant 464 000 noms de domaines sont tombés (dixit Netcraft). Les sites en panne ne se comptent plus. Le groupe français évoque 12 000 à 16 000 clients concernés. Parmi les infrastructures touchées, le datacenter Strasbourg 2 (SBG2) dans lequel le feu a pris a été entièrement ravagé par les flammes. Quatre salles serveurs de SBG1 sur douze sont parties en fumée. A l'heure où nous écrivons ces lignes, le plan de reprise d'activité d'OVH est toujours en cours sur SBG3 et SBG4. Les serveurs détruits sur SBG1 et SBG2 sont remplacés par de nouvelles machines déployées dans d'autres centres de données du provider français. Quant aux serveurs encore fonctionnels sur SBG1, ils sont aussi déplacés sur d'autres datacenters d'OVH. Alors que les Gafam continuent de s'étendre en Europe avec une force concurrentielle sans merci, c'est une véritable déflagration pour la French Tech dont l'image va de facto se ternir. Son porte-flambeau a subi la plus importante catastrophe industrielle de son histoire. Menée par la Sûreté départementale du Bas-Rhin, une enquête est en cours pour faire toute la lumière sur cette affaire. En attendant, plusieurs zones d'ombre demeurent.

1. Les datacenters Strasbourg 1 et Strasbourg 4 devaient être fermés

La décision de fermer les datacenters SBG1 et SBG4 avait été prise en novembre 2017 suite à une panne électrique sur le site de Strasbourg. Panne qui avait engendré une coupure de courant complète sur SBG1, SBG2 et SBG4. Elle provenait d'un dysfonctionnement dans le système de bascule vers les groupes électrogènes de secours suite à la défaillance d'un automate.

Dans son rapport d'incident, l'entreprise d'Octave Klaba détaille un plan d'actions précis. Parmi les décisions prises, il mentionne la fermeture de SBG1 et SBG4, les seuls de ses centres de données conçus à partir de containers (voir capture ci-dessous). "Nous avons réalisé que le datacenter en containers maritimes n'est pas adapté aux exigences de notre métier", explique alors OVH en évoquant la limite de ce modèle pour gérer la forte croissance de son infrastructure. Mais force est de reconnaître que le 10 mars 2021, SBG1 et SBG4 étaient toujours en fonction.

2. Le datacenter SBG4 n'était pas indépendant énergétiquement

Suite à l'incendie, Octave Klaba a annoncé sur Twitter le déploiement "d'un nouveau câble électrique pour connecter SBG3 avec SBG4" en vue de réalimenter ce dernier en énergie. Conclusion : SBG4 qui, rappelons-le a été épargné par les flammes, ne dispose pas de sa propre ligne électrique. En toute logique, il devait dépendre sur ce plan d'un des deux centres de données touchés, SBG1 ou SBG2.

Là-encore, cette architecture aurait dû être abandonnée au profit d'un réseau électrique indépendant d'un datacenter à l'autre. "C'est le cas partout sauf sur le site de Strasbourg", indiquait OVH dans son rapport d'incident de 2017, tout en prenant l'engagement de "séparer le réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, et séparer celui du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4".

3. SBG3 n'avait pas sa propre salle réseau

Officiellement, le datacenter SBG3 n'a pas subi de dommages matériels, même si ses serveurs impliquent d'être vérifiés voire nettoyés avant d'être redémarrés. Suite à l'incendie, OVH indique pourtant avoir dû mettre en place une nouvelle salle réseau en vue de le remettre en production. On peut légitimement se demander pourquoi, mais le groupe n'a jusqu'ici donné aucune explication à ce sujet. L'explication la plus logique ? La salle réseau de SBG3 était hébergée au sein de SBG2.

4. Des backups étaient réalisés sur le même datacenter

Au sein de son offre de cloud privé managé (Private Cloud), OVH ne proposait pas de service de backup déporté avant avril 2020. Ses clients ayant souscrit à cette offre auparavant ne disposent donc pas de la nouvelle option. L'ensemble des utilisateurs de Private Cloud localisés sur SBG2 semblent être dans ce cas. OVH a en effet clairement indiqué que leur sauvegarde était irrécupérable. Idem pour ceux adossés à SBG1. Octave Klaba le confirme sur Twitter : "Les sauvegardes gratuites et payantes de Private Cloud dans SBG1 étaient hébergées dans une autre salle du centre de données. Les deux sont détruites."

Mais Private Cloud n'est pas la seule offre concernée. De l'hébergement web aux services de cloud public en passant par les serveurs privés virtuels et le bare metal, OVH reconnaît que de nombreux backups sont non-récupérables. "La responsabilité de la conception et de la mise en place d'un plan de reprise d'activité incombe aux entreprises, et non au fournisseur de service cloud ou à l'hébergeur. Seule l'activation du plan et son exécution peuvent être partagées entre le fournisseur et le client", rappelle sur ce point Luc D'urso, CEO d'Atempo Wooxo, société française experte en cybersécurité (lire sa chronique : Les leçons à tirer de l'incendie du datacenter d'OVHCloud).

5. Les planchers du datacenter SBG2 étaient en bois

L'information a été confirmée par les sapeurs-pompiers intervenant sur le site. "Les planchers (du datacenter SBG2, ndlr) sont en bois", a indiqué à l'AFP dans la nuit du sinistre Damien Harroué, commandant des opérations de secours et adjoint au chef de la sous-direction opérations-prévention au Service Départemental d'Incendie et de Secours 67. Mis en service en 2014, SBG2 est une tour autoventilée fonctionnant par différence de pression entre le haut et le bas de l'édifice. Avec une capacité totale de 1 900 m2, elle s'élève sur cinq étages. Le bois était par conséquent présent à tous les niveaux de la structure. Une photo prise lors de la construction de SBG2 et publiée par Octave Klaba sur son compte Twitter en 2013 confirme cette information (voir ci-dessous).

6. L'absence de système d'extinction automatisé sur SBG2

Force est de constater que le datacenter SBG2 n'était pas doté d'un réseau d'extinction d'incendie automatisé. La procédure en cas de départ de feu était manuelle. Octave Klaba l'explique à demi-mot dans une vidéo publiée sur Twitter le 11 mars, dans laquelle il revient sur les circonstances de l'événement. "A 00h47 le 10 mars, les alertes et alarmes du système de détection anti-incendie se sont déclenchées. Les deux techniciens basés sur place et le personnel en charge de la sécurité du site sont intervenus immédiatement sur les différentes salles d'où provenaient les alertes. Ils ont vu beaucoup de fumée noire. Au bout d'une à deux minutes, ils ont pris la décision de sortir du datacenter (sans pouvoir intervenir, ndlr) car ça devenait trop dangereux pour eux de rester à l'intérieur."

En général, les centres de données sont équipés soit d'un réseau de brumisateurs haute pression permettant de résorber les flammes tout en protégeant les machines contre l'eau, soit d'un système de diffusion de gaz inerte. Un gaz qui a pour vocation de vider les salles serveurs de leur oxygène pour étouffer l'incendie en évitant là-encore de causer des dégâts aux équipements.

Contacté par le JDN, OVHCloud n'a pas souhaité commenter ces informations. "Les investigations des pouvoirs publics et des compagnies d'assurance sont en cours pour comprendre la chronologie, le foyer et les modalités de propagation de l'incendie et ainsi pouvoir déterminer la cause de cet incendie. Pour l'instant, il est trop tôt pour tirer des conclusions", indique un porte-parole du groupe au JDN, qui renvoie vers le lien relatif à ses services de backup sur le campus de Strasbourg.