Incendie de OVH SBG2 Incident évitable ?

par | 7 05 2021 | Dossiers

Que s’est-il passé le soir du 9 mars 2021 au datacentre SBG2 strasbourgeois d’OVH pour que ce dernier s’embrase et finisse entièrement carbonisé ? Disparues les données qui y étaient hébergées ! L’enquête le dira certainement, mais sans attendre ses conclusions, il est déjà possible d’émettre quelques hypothèses. Partons de faits qui semblent établis. Article publié dans L’Informaticien n°195.

Le premier élément à prendre en compte dans les causes de l’incendie est la conception du datacentre. Il est de notoriété publique, comme en témoignent des photographies publiées sur Internet, que les structures internes des datacentres d’OVH sont en bois. Un matériau certes résistant, léger et écologique, mais qui n’est pas vraiment ignifugé, c’est le moins que l’on puisse dire.

Là-dessus, on sait maintenant que le datacentre strasbourgeois – probablement comme tous les datacentres d’OVH en France – n’était pas équipé d’un système anti-incendie à aspersion d’eau. On peut s’interroger sur la raison d’un tel manquement, et ce, d’autant que les datacentres d’OVH situés au Québec sont, eux, équipés d’un tel système. Sur la liste de discussion fr-nog, un contributeur rapporte les propos d’un employé d’OVH à propos des systèmes d’extinction : « Pour avoir visité Roubaix 4 il y a quelques années, il n’y a pas non plus de système d’extinction d’incendie. J’avais relevé cela auprès de la personne qui a fait la visite et la réponse était : “Ça coûte cher pour un risque quasi nul. ”»

Le datacentre RBX 4 en construction. Les planchers sont clairement en bois.
Le même datacentre après construction.

À en croire un post assez ancien du site lafibre.info (https://lafibre.info/ovh-datacenter/ovh-et-la-protection-incendie/ msg80633), « Quasiment tous les bâtiments aux États-Unis et au Canada sont équipés d’aspergeurs, qui sont quasi-obligatoires réglementairement parlant et côté assurance. […] En France, les datacentres sont réglementés essentiellement par le code du travail, par les préconisations ICPE (à autorisation ou déclaration) et par les assureurs. Au niveau purement réglementaire, les seules choses demandées sont :
 – le désenfumage mécanique ou naturel pour les locaux aveugles ou faisant plus de 300 m²;
– le compartimentage coupe-feu au-delà d’un certain volume / métrage;
– des issues de secours accessibles avec une certaine largeur;
– une ventilation donnant un minimum d’air neuf par occupant; – l’accessibilité pompier par la facade pour les locaux dont le plancher bas du dernier niveau est à plus de 8 mètres.
»

Il est à noter que ces informations datent de 2013… Mais comme il n’y a jamais vraiment eu de sinistre dans des datacentres, il y a peu de chances que la réglementation ait changé depuis lors.

Le datacentre alsacien est donc probablement en structure bois, sans système d’extinction d’incendie. Tout le monde sait qu’un bâtiment rempli de câbles électriques dans lesquels circulent plusieurs centaines d’ampères court un risque. Peu importe la tension d’ailleurs, puisque la dissipation de chaleur par effet joule est proportionnelle au carré de l’intensité, et que les étincelles caractéristiques des ruptures de courant dans les circuits inductifs se manifestent quelle que soit la tension de fonctionnement.

Des vidéos disponibles sur YouTube montrent les effets désastreux que peuvent avoir des courts-circuits dans de telles installations (par exemple : www.youtube.com/watch?v=DpQeDcEpEn0). En plus de ce risque inhérent à toute salle électrique, il semble que les onduleurs destinés à assurer la continuité électrique avaient été installés dans le même bâtiment que les serveurs, au rez-de-chaussée – en raison du poids de ces équipements de secours, que la plupart des planchers ne pourraient pas porter.

Que se passe-t-il lorsque l’une des batteries cesse de fonctionner normalement ? Examiner une salle remplie d’onduleurs n’est pas une tâche évidente, et ce d’autant que les batteries défectueuses ne sont pas toujours immédiatement repérables. En principe, ces dernières doivent se mettre à chauffer de plus en plus (emballement), mais cette hausse est parfois légère et peu évidente au début, et peut passer inaperçue, même aux dispositifs de protection intégrés aux onduleurs. On pense savoir que certains de ceux-ci avaient fait le jour même du sinistre l’objet d’opérations de maintenance. Y aurait-il eu mauvaise manipulation, par exemple une inversion de polarité? On se souvient que l’hébergeur avait déjà eu des soucis électriques dans ce même datacentre en 2017, où des groupes électrogènes n’avaient pas démarré malgré une panne d’alimentation (cf. https://www.numerama.com/ business/304644-bfm-business-cozycloud-une-importante-panne-chezovh-affecte-plusieurs-sites.html).

Il semble maintenant établi que c’est bien un de ces onduleurs qui a pris feu. Or, du fait de la proximité des autres équipements, et faute de dispositif d’extinction, l’incendie a dû se propager rapidement. Et c’est là qu’intervient un troisième facteur : SBG2 avait été conçu pour être refroidi par un système de convection passif qui, par effet de cheminée, admettait de l’air froid par le bas du bâtiment, et évacuait l’air chaud par le haut. Le bâtiment avait subi différentes modifications depuis 2015, mais qu’en était-il exactement du système de refroidissement ? Mystère. Or il va de soi qu’une alimentation constante en air frais depuis le sol n’a pu qu’attiser les flammes qui ravageaient le bâtiment.

Miroir aux alouettes ?

La manière dont l’incident a été géré par OVH a également largement prêté à commentaire. Les interfaces de gestion des services cloud, comme le manager, ont cessé de fonctionner, alors même que les clients cherchaient en urgence à accéder à ces fonctionnalités, par exemple pour changer les A ou AAAA records afin de faire pointer les URL vers des sites de secours hébergés ailleurs, ou activer les IP failovers (certains rapportent même que leurs machines virtuelles avaient disparu de l’interface). La plupart des utilisateurs professionnels de l’infrastructure disposaient d’un « PRA », un plan de reprise d’activité, c’est-à-dire un ou plusieurs backups physiquement distants et mobilisables quasi-immédiatement ; ceux-là n’ont eu à déplorer que quelques heures d’indisponibilité. Ce n’est malheureusement pas le cas des petites ou moyennes structures, PME ou collectivités locales, sans véritables compétences en termes d’architecture informatique. Pour ceux-là, à moins d’avoir pensé à réaliser une sauvegarde récente en local, tout est littéralement «parti en fumée». Pis, il semble que le service «snapshot quotidien», proposé par OVH pour précisément pallier une perte de données sur un disque dur, se soit révélé inutile, car les serveurs qui stockaient ces snapshots se trouvaient dans le même datacentre afin d’optimiser le trafic réseau…

Encore une fois, on constate que les petites structures, sans beaucoup de moyens, sont souvent victimes d’un discours marketing martelé à l’encan par les principaux hébergeurs et opérateurs du Cloud, à savoir que délocaliser ses données «quelque part» dans le réseau revient à les prémunir contre ce genre de mésaventure – quitte parfois à faire jouer une certaine confusion sémantique sur le terme «données sécurisées». L’incendie de Strasbourg montre que cela n’est hélas pas le cas. Transférer ses données dans le Cloud, c’est certes faire l’économie de l’achat de matériel informatique, et surtout de la location d’une liaison rapide pour faire vivre son site, mais il est illusoire de penser que les offres à petits prix, comme celles proposées par OVH, vont avec une garantie sur la pérennité des données. Coût minimal, service minimal. Ce principe de bon sens s’applique également pour l’hébergement informatique, quelle que soit la société choisie. Beaucoup pensent encore que l’hébergeur est responsable des données qui lui sont confiées. C’est évidemment faux. Payer peu, c’est accepter de se retrouver hébergé sur une machine virtuelle située dans un datacentre peut-être mal conçu, sans redondance en cas de coup dur, en dépit de ce que laissent entendre les grands opérateurs. Il serait peut-être temps que les ministères compétents se penchent sur la question et prennent des décisions : réglementer la sécurité des datacentres, et obliger les hébergeurs à informer clairement leurs clients des conditions de conservation de leurs données.


Le Livre Blanc sur la sécurité incendie des datacenters

Nous avons invité France Datacenter a exprimé son point de vue sur l’incendie de Strasbourg.

« France Datacenter est une association professionnelle qui regroupe un peu plus de cent adhérents qui conçoivent, construisent et exploitent les datacenters […]. Nous sommes solidaires d’OVH dans les difficultés que cet opérateur français rencontre actuellement. Nous les connaissons bien et les avons invités à nous rejoindre. Actuellement ils ne sont pas adhérents à France Datacenter […].

La filière a toujours traité le sujet de la sécurité incendie comme un risque majeur, même s’il ne se concrétise que très rarement par un arrêt de service ou une destruction de bâtiment. Un livre blanc a été publié en 2019, intitulé « La sécurité-incendie dans les datacenters ». Elle a été réalisée en intelligence collective, grâce aux précieuses contributions écrites de nos adhérents. Ce Livre Blanc permet à tout exploitant de salle informatique d’être accompagné dans la mise en œuvre des meilleures solutions de protection incendie. Il aide à définir une méthode d’analyse du risque la plus adaptée à son environnement de travail et ainsi optimiser l’exploitation de son installation.

Aujourd’hui, à ce stade, nous sommes dans l’attente, comme l’ensemble des acteurs de la filière, des résultats de l’analyse en cours et des conclusions de l’enquête. Enfin, cet incident rappelle que chaque client final doit avoir une stratégie de sauvegarde adaptée. »


Point de vue

Les nombreuses leçons à tirer de l’incendie OVH

par Sébastien Enderlé

« L ’incendie des datacenters d’OVH interroge toute notre industrie et nous devons en tirer les leçons qui s’imposent. Sur le plan normatif la France ne bénéficie pas à mon sens d’un arsenal juridique suffisant afin d’éviter ce type d’accident industriel. Les datacenters d’OVH n’étant pas classifiés comme ERP (établissements recevant du public) ni IGH (Immeuble grande hauteur) ils ne sont soumis qu’au code de l’habitation et de la construction ainsi qu’au code du travail. En ce sens OVH satisfait donc à ses obligations réglementaires. Je rappelle que ces réglementations ne prévoient que l’obligation de se doter de systèmes d’alarme, d’alerte et d’évacuation (articles R4227-1 à R4227-41 et R.4227-55 à R4227-57) ainsi que d’extincteurs (APSAD R4).

Cependant s’agissant spécifiquement de datacenters nous héritons de responsabilités supplémentaires qui relèvent du bon sens, de l’état de l’art et du respect de notre clientèle.

Pour cette raison les datacenters sérieux ont depuis longtemps adopté un ensemble de contre-mesures anti-incendie basées sur un ensemble de normes (notamment APSAD mais aussi ISO et Uptime Institute).

Quelques bonnes pratiques

Voici par exemple quelques-unes des mesures adoptées par ASPSERVEUR ainsi que par la plupart des acteurs industriels.

Construction en béton : l’acier perd ses qualités structurelles à partir de 400°C contre 750°C avec le béton qui bénéficiera encore d’une tolérance de +/- 35%.

APSAD R15 et R16 : chaque local technique (onduleurs, TGBT, climatisation, salles blanches…) est isolé des autres par des ouvrages séparatifs coupe-feu et des fermetures coupe-feu.

APSAD R7 : sétection automatique d’incendie. Les systèmes de détection automatique d’incendie sont chargés de détecter et de signaler le plus tôt possible la naissance d’un incendie, tout en évitant de déclencher des alarmes injustifiées.

APSAD R13 : extinction automatique à gaz. Dans le cas d’ASPSERVEUR nous utilisons un système CERBERUS SIEMENS à azote. Les salles blanches sont étanches et dotées de trappes de suppression, en cas de départ de feu les molécules d’oxygène sont remplacées par des molécules d’azote ce qui éteint l’incendie en quelques minutes sans abîmer les serveurs informatiques.

APSAD R5 : robinets d’incendie armés et postes d’incendie additivés et APSAD R4, extincteurs portatifs et mobiles.

APSAD R6 : maîtrise du risque incendie et du risque industriel. Ce référentiel apporte les éléments nécessaires à une maîtrise du risque incendie et du risque industriel dans l’entreprise. Il décrit les exigences d’organisation, les missions des équipes d’intervention et définit les moyens matériels que doit posséder l’établissement. Les exigences doivent s’adapter au niveau de risques de l’entreprise et ainsi se développer progressivement et de façon modulaire.

Certification ISO 27001 : cette certification oblige à respecter un ensemble de processus et de mesures anti-incendie, par exemple l’interdiction du stockage de matières inflammables. De plus nous considérons comme exigible à un PRA les datacenters secondaires situés à plus de 30 km du datacenter nominal. À mon sens le fait de considérer des datacenters collés entre eux comme étant de multiples datacenters est une vue de l’esprit. La preuve en est que l’incendie du datacenter OVH SGB2 s’est propagé au datacenter SGB1 mais, plus grave encore, il a fallu mettre SGB3 et SGB4 hors de fonctionnement durant l’incendie !

En tant que dirigeant fondateur d’ASPSERVEUR, sur 22 ans j’ai eu à faire des choix entre rentabilité et sécurité, j’ai audité des datacenters, j’en ai construit un et exploité plusieurs en France et aux États-Unis. Je ne pense pas que le low-cost soit incompatible avec la qualité mais il faut savoir où placer le curseur. Bien qu’étant toujours aux côtés d’ASPSERVEUR, je dirige désormais une société de conseil en externalisation informatique car les aspects normatifs et sécurité sont plus que jamais d’actualité. »

FIL DES DOSSIERS…

DERNIERS DOSSIERS…

Améliorer son code Python

La syntaxe de Python est très permissive. Pour uniformiser l’écriture de code, la communauté des développeurs Python recommande un certain nombre...

Vos abonnements

  • Vous n'êtes pas connecté

Derniers commentaires

Plus d’infos sur…

Inscription Newsletter