Incendie d’OVHcloud : l’enquête se dirige vers l’explosion d’un onduleur
Un onduleur en maintenance le jour même serait peut-être, selon les pompiers, la cause du départ du feu. En attendant, la panique règne chez les clients inquiets de ne pas retrouver leurs contenus.
L’incendie qui a détruit le bâtiment SBG2 de l’hébergeur OVHcloud dans la nuit de mardi à mercredi pourrait être dû au dysfonctionnement d’un onduleur qui avait subi une intervention le jour même. C’est du moins l’hypothèse qu’Octave Klaba, le président fondateur d’OVHcloud, fait dans une communication vidéo diffusée jeudi 11 mars : « Quand les pompiers sont intervenus, entre 10 et 15 minutes après le début de l’alerte, ils ont utilisé des caméras thermiques qui ont montré deux onduleurs en feu. L’un d’eux, le PS7, avait subi une intervention le matin même. Le technicien de maintenance avait changé beaucoup de pièces à l’intérieur et avait remis l’onduleur en route dans l’après-midi. Il semblait alors fonctionner normalement », dit-il.
Un onduleur permet d’assurer l’alimentation en électricité des serveurs en cas de défaut dans l’arrivée du courant, à savoir une coupure ou une surtension sur le réseau du fournisseur d’électricité. Pour ce faire, il est équipé de batteries qui prennent le relais en cas de panne.
« De ce fait les onduleurs utilisent des batteries avec des composants qui dégagent de la chaleur (lithium Ion, lithium, thyristors, transistors, Diodes…). Et si cette chaleur n’est pas correctement dissipée, ces composants brûlent. Il est alors trop tard, car il s’agit d’équipements qui contiennent des produits inflammables, explosifs », explique Franquelin Lopes, directeur technique du Jiliti, un prestataire expert dans la conception des datacenters.
« Les onduleurs de grosses puissances sont généralement associés à des dispositifs permettant de dissiper la température, lesquels comprennent une ventilation et un contrôle obligatoire lors de maintenances régulières. Une mauvaise ventilation, ou une maintenance défaillante peuvent provoquer une augmentation de la température de ces onduleurs. Et c’est cette chaleur qui est susceptible de provoquer l’incendie dans un datacenter. Selon une étude du Laboratoire Lavoue, 4 % des incidents dans un datacenter sont liés aux onduleurs », ajoute l’expert.
Octave Klaba assure qu’une enquête sera menée : « nous avons 300 caméras dans le datacenter. Nous devons analyser les images pour comprendre exactement ce qu’il s’est passé avant l’incendie, au moment où l’incendie a démarré et comment le feu s’est propagé, mais aussi pour comprendre comment améliorer notre sécurité. »
La conception écologique du bâtiment a pu nuire à sa sécurité
Mais, surtout, Octave Klaba note un départ de feu extrêmement rapide : « Les techniciens sur place sont intervenus en quelques dizaines de secondes après le déclenchement de l’alerte. Mais au bout de seulement une minute la fumée était telle, qu’ils ont décidé de sortir du bâtiment, car la situation était devenue trop dangereuse. La rapidité de ce feu nous interroge. »
La raison de cette propagation extrêmement rapide du feu pourrait être due à la conception du bâtiment, qui a été construit en 2011 dans l’optique de surtout favoriser l’aspect écologique :
« SBG2 est une tour autoventilée où, pour réduire l’impact environnemental, le refroidissement se fait par la circulation naturelle de l’air, grâce à la différence de pression entre le bas et le haut de la tour », dit Octave Klaba. Il constate que le bâtiment voisin, SBG3, de conception entièrement différente, plus moderne, n’a pas été impacté par le feu, alors qu’il est accolé à celui qui a été détruit par les flammes.
Selon les informations que LeMagIT a obtenues, SBG2 serait une tour construite avec une cour intérieure dont le vide servirait à faire rapidement circuler l’air de bas en haut. Dans SBG3, en revanche, toute la surface des différents étages serait occupée par des rayonnages de serveurs, segmentés en salles étanches. SBG1, le bâtiment le plus ancien du site et situé à l’autre extrémité de SBG2, n’avait aucune conception particulière et a vu ses quatre salles les plus proches de SBG2 également ravagées par les flammes.
La restauration des contenus : la véritable angoisse des clients
Outre l’enquête, la préoccupation principale d’OVHcloud est pour l’heure de surtout faire repartir l’activité. Cela comprend deux points : construire le plus rapidement possible des milliers de serveurs pour remplacer ceux qui ont disparu dans les flammes – le bâtiment SBG2 en contenait 12 000. On ignore combien ont été détruits dans les quatre salles de SBG1 qui ont pris feu.
Mais il s’agit aussi – et surtout – de restaurer dans ces nouvelles machines les données qui étaient dans les anciennes. Or, c’est bien ce sujet-là qui cristallise toutes les angoisses et tous les fantasmes parmi les clients d’OVHcloud.
Dans les heures qui ont suivi l’annonce de l’incendie, LeMagIT a reçu de nombreux témoignages – souvent indirects, souvent réclamant l’anonymat – suggérant qu’OVHcloud n’aurait pas été en mesure d’assurer la sécurité des données de ses utilisateurs. Et qu’il aurait, à cause de sa supposée négligence sur les aspects sécuritaires, provoqué la destruction des données essentielles à l’activité économique de nombreuses sociétés. Parmi ces témoignages, des web-agencies, tenues d’indiquer à leurs clients quand leurs sites web seront de retour en ligne, prétendent qu’elles avaient bien des sauvegardes, mais qu’OVHcloud les leur aurait installées sur les mêmes serveurs que ceux de production, les rendant de fait irrécupérables.
« La responsabilité d’un hébergeur porte sur la fourniture d’un service, qui est d’héberger et diffuser un site web ou des données. Mais pas sur la garantie de sauvegarde elle-même, sauf si vous avez souscrit un contrat explicite. »
Arnold ZephirData scientist, Prevision.io
Anorld Zephir, data scientist chez le prestataire Prevision.io, lui-même client d’offres hébergées, pointe un problème de responsabilité de la part de ces entreprises : « la responsabilité d’un hébergeur porte sur la fourniture d’un service, qui est d’héberger et diffuser un site web ou des données. Mais pas sur la garantie de sauvegarde elle-même, sauf si vous avez souscrit un contrat explicite. »
« Évidemment, il y a souvent des backups assez basiques que l’hébergeur effectue juste pour garantir que, en cas de problème mineur (une panne de courant, la destruction d’un seul serveur), il peut rapidement relancer le service. Ce sont ces sauvegardes-là qui sont situées sur un serveur juste à côté. Mais si vos données sont très importantes, il est de votre responsabilité de vous assurer que des plans de sauvegardes bien faits, à hauteur de la valeur de vos données, existent. L’hébergeur ne peut pas être au courant de la valeur exacte des données qu’il héberge pour chaque client », dit-il, en suggérant que les entreprises devaient demander elles-mêmes à OVHcloud d’héberger leurs sauvegardes sur des sites différents de ceux de production.
Yohann Berhouc, directeur général du cabinet de conseil Cyrès, pointe que les entreprises clientes d’OVHcloud n’ont peut-être compris que tout récemment que la responsabilité des sauvegardes leur incombait. « Le diable se cache souvent dans le détail. Avec le cloud, on a malheureusement l’impression que tout est inclus. Or, il est du devoir de chacun de comprendre ce qui est inclus dans les plans qui sont souscrits. La sauvegarde des données, un plan de continuité d’activité sont des options qui entraînent des frais complémentaires. Ce sont des assurances, mais aucune n’est obligatoire. Ce sont des activités très différentes de l’hébergement. Elles supposent des engagements supplémentaires et surtout un vrai investissement en temps et en dialogue avec le prestataire. Or, l’urgence, le budget, la disponibilité des équipes, peu rompues à l’exercice, entraînent ce type de situation, trop courantes malgré les alertes multiples », commente-t-il.
Anorld Zephir rappelle la sacro-sainte règle des 3 en matière de protection des données : une copie des données sur le serveur principal, une copie sur un serveur physiquement distant du premier (à minima sur un autre site) et une copie physique sur un troisième site, typiquement dans les bureaux de l’entreprise cliente. Parmi les web-agencies entrées en contact avec LeMagIt, l’une d’elles a indiqué qu’elle possédait bien une copie de secours du site de son client sur ses propres disques durs. Mais celle-ci date de 2017.
Construire 3 000 serveurs de remplacement par jour
De toute manière, tous les serveurs du site SBG d’OVHcloud étant actuellement à l’arrêt, il est difficile de savoir ce qui a été définitivement perdu, ce qui est récupérable et ce qui est juste momentanément hors-ligne. « Parfois les données primaires et les backups sont dans deux salles différentes. Parfois dans deux bâtiments différents. Parfois sur deux sites différents. Nous sommes en train de faire l’inventaire », indique Octave Kabla.
La réponse devrait arriver ce week-end, mais il n’est pas certain que les services puissent redémarrer sur SBG la semaine prochaine : « remettre en route les salles épargnées par le feu est compliqué. Nous espérons que cela pourra être fait la semaine prochaine », dit le président d’OVHcloud, sur un ton moins affirmatif que lors de ses premiers tweets, qui promettaient un redémarrage de SBG3 et SBG4 dès le lundi 15 mars, puis de SBG1 le vendredi suivant. En l’occurrence, outre les dégâts physiques provoqués par les flammes, les fumées toxiques qui ont pu passer par les gaines techniques peuvent supposer de décontaminer l’intégralité des bâtiments. En plus de nécessiter une identification pointilleuse de chaque centimètre carré de câble électrique.
Aux dernières nouvelles, SBG1 et SBG4 seraient plutôt rallumés à partir du vendredi 19 mars et il faudra attendre deux jours pour que tous leurs serveurs aient redémarré. SBG3 pourrait être rallumé mercredi 17 mars. Ses serveurs mettront six à huit jours avant d’être entièrement restaurés et de nouveau en ligne.
En attendant, OVHcloud s’attèle à déployer de nouveaux serveurs sur ses autres sites de Roubaix et Gravelines pour prendre la relève de ceux de Strasbourg. « Nous avons assemblé le premier jour 2 000 nouveaux serveurs. Nous mettons les bouchées doubles pour passer à 2 500 ou 3 000 nouveaux serveurs par jour », dit Octave Klaba.
Les clients des offres de cloud public et de cloud privé auront automatiquement des ressources allouées sur ces nouvelles machines. OVHcloud garantit qu’il restaurera par défaut toutes leurs couches d’infrastructures : machines virtuelles, noms de domaines, systèmes Linux ou Windows. Quant aux données à mettre dedans, cela dépendra donc des fameuses sauvegardes, faites ou non, contractées ou non, par les clients.
Franquelin Lopes salue pour sa part l’étonnante capacité d’OVHcloud à produire lui-même ses serveurs, qui plus est à un rythme aussi soutenu : « Les serveurs OVH sont extrêmement intéressants, car ils permettent de mutualiser des composants tels que les alimentations, les ventilateurs… Leur design est une réelle source d’économie, à la fois dans la phase de fabrication et dans celle d’exploitation, et de gain de temps. »
