Auteur Sujet: Rapport d’enquête BEA-RI sur l’incendie du datacenter OVH de Strasbourg en 2021  (Lu 83288 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Quelques vidéos tournées sur place :




vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info


Je ne vois aucun réponse, le sujet n'est pourtant pas verrouillé  ;)

toshopp

  • Abonné Orange Fibre
  • *
  • Messages: 196
  • FTTH Sosh 300/300 - St Cloud (92)
Disons qu'il va falloir un peu de temps pour digérer cette montagne d'information très intéressante!  ;D

Merci!!  ;)

Sylv_01

  • Abonné Orange Fibre
  • *
  • Messages: 359
C'est exactement ce que j'étais en train d'écrire !  ;D

ldrevon

  • AS43142 Officiel Adeli
  • Expert
  • *
  • Messages: 642
Super dossier et très instructif.
Bon en bref le retardant et le bois , ce n'est pas l'idéal (mise à part sauver des gens???)
Empiler des boites : bon ce n'est pas non plus l'idéal.
Ne pas mettre de sécurité incendie , ce n'est pas une bonne idée!
La vraie question c'est quand même : quelle est la marque des onduleurs?, Est-ce qu'il y a des logs?
Les batteries des onduleurs peuvent être victimes d'emballement thermique (suite problème de clim?) et normalement les onduleurs savent gérer ce problème, cela n'aurai t pas du arriver.
Par contre sous l'eau effectivement ce n'est pas garantie! La question est donc est-ce l'eau qui a fait cramer les onduleurs ? ou est-ce l'incendie qui a fait  fondre le système de refroidissement!?

Sans critiquer OVH (mais un peu quand même  ;) ), on est quand même dans la vraie vie et les limites financières provoquent ce genre de situation.

ldrevon

  • AS43142 Officiel Adeli
  • Expert
  • *
  • Messages: 642
On a plus qu'a attendre la fin de l'enquête pour savoir si c'est la poule ou l’œuf le responsable  :D

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Les pompiers mentionnent dans leur retour d'expérience : Arcs électriques de plus d'un mètre autour de la porte du local "énergie" => Flash impressionnants et bruits assourdissants.
Il semble donc que ces arcs électriques étaient formés par du 20 000 volts (impossible d'avoir de tels arcs avec du 400 volts).

Pour moi ce qu'il manque comme information dans ce rapport, ce sont les tensions utilisées dans ce que le rapport nomme l'ASI (le système d’alimentation sans interruption).

- L'arrivée du côté d’Électricité de Strasbourg Réseau (ESR) se fait en 20 000 volts
- Les groupes électrogènes de DC2 sont également en 20 000 volts (il y a un transformateur pour monter la tension dans le groupe)


En sortie de chaque groupe, un transformateur 400v vers 20 000v :



On ne sais pas où sont les transformateurs pour abaisser la tension.

Il y a des datacenter où la sortie de l'onduleur on a un transformateur pour remonter la tension en 20 000 volts (d’après ce que j'ai compris, cela permet des économies)
Ce serait le cas ici ?

Où les onduleurs alimenteraient directement les serveurs en 400 volts (soit du 230 volts entre le neutre et une des 3 phases)
Ces histoires de tensions ne sont pas anecdotiques, vu que l'on est sur un feu d'origine électrique.

Post moterm de l'incident de novembre 2017 :


Bonjour,
Voici le post-mortem de l'incident.

Le jeudi 9 novembre, à 7 h 04, le site de Strasbourg, hébergeant 4 datacentres, a été privé d’énergie. Malgré toutes les sécurisations mises en place, la coupure électrique s’est propagée dans les datacentres et a provoqué un arrêt électrique de 40 386 serveurs hébergés sur le site.

À 10 h 39 le site a été réalimenté, puis les services ont progressivement redémarré. A 18 h 00, 71 % des serveurs étaient fonctionnels, et le vendredi 10 novembre à 23 heures, 99 % des serveurs étaient fonctionnels. Une minorité de services a été affecté jusqu’au dimanche 12 novembre.


Déroulé de l’incident en temps réel (jeudi 9 novembre) :
----------------------------------------------------------
7h04:07 : disjonction du côté d’Électricité de Strasbourg Réseau (ESR) et perte de l’alimentation électrique des deux lignes.
7h04:17 : les groupes électrogènes haute tension (HT) ne démarrent pas.
7h12:48 : l’onduleur 6 (UPS) arrive en fin d’autonomie batterie.
7h15:48 : l’onduleur 5 arrive en fin d’autonomie batterie.
7h17:25 : l’onduleur 2 arrive en fin d’autonomie batterie.
7h18:00 : les premières tentatives manuelles de redémarrage des groupes HT ont échoué.
7h18:39 : l’onduleur 1 arrive en fin d’autonomie batterie.
7h19:19 : l’onduleur 4 arrive en fin d’autonomie batterie.
7h21:00 : l’onduleur 3 arrive lui aussi en fin d’autonomie batterie.
7h21:00 : les salles de routage ne sont plus alimentées électriquement.
7h21:03 : nouvelle tentative manuelles de démarrage du groupe HT numéro 1.
7h22:42 : nouvelle tentative manuelles de démarrage du groupe HT numéro 2.
7h30 : la cellule de crise locale est opérationnelle.
7h50 : la cellule de crise centrale au siège de Roubaix est opérationnelle.
Entre 7h50 et 10h39 : multiples tentatives manuelles de redémarrage des groupes électrogènes accompagnées par nos experts en génie électrique.
10h39 : ESR rétablit l’alimentation secteur.
10h58 : les routeurs sont de nouveau joignables.
11h : les interventions sur les serveurs le nécessitant sont en cours.
14h : arrivée d’une première équipe renfort
16h : des renforts venus de nos sites de Francfort (Allemagne) et de Roubaix arrivent.
17h30 : un camion de 38 tonnes rempli de pièces détachées arrive sur place.
22h : 97 % des serveurs fonctionnent, 91 % répondent au ping.


Quelle est la cause de la disjonction côté ESR ?
------------------------------------------------
L’ensemble du site est alimenté par 1 alimentation électrique de 20MVA réalisée avec 2 câbles de 20kV. La cause de la disjonction est liée à une altération d’un des 2 câbles souterrains, qu’ESR a réparé rapidement. Les causes de l’altération de ce câble ne sont pas encore déterminées à date. Des investigations sont en cours par ESR.


Pourquoi la perte d’un câble a entraîné une coupure d’alimentation ?
--------------------------------------------------------------------
Le site de Strasbourg est alimenté par deux câbles délivrant 20MVA et donc connectés sur le même disjoncteur. Le déclenchement du disjoncteur a entraîné la coupure des deux lignes.


Pourquoi les générateurs haute tension ne se sont-ils pas mis en route ?
------------------------------------------------------------------------
SBG1 et SBG4 sont alimentés par 2 groupes électrogènes (HT), de 2MVA chacun, qui prennent le relais en cas de coupure électrique. L’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas démarré les groupes électrogènes.

Après investigation, nous avons constaté que l’ordre de démarrage des groupes haute tension (HT) n’avait pas été envoyé par l’automate pilotant l’inverseur.

Le fabriquant de cet automate est venu l’expertiser. Il s’avère qu’il était bloqué en défaut « automatisme verrouillé », ce qui explique l’absence de démarrage des groupes HT. Des investigations sont en cours pour comprendre l’origine de ce blocage.

L’équipe d’intervention du fabricant a remis l’automate en état de fonctionnement normal. Nous n’avons pour l’instant pas d’explication à cette erreur. En l’attente des conclusions, nous assurons la permanence en roulement d’une personne dédiée 24 heures/24 et 7 J/7 afin d’être en mesure de forcer la bascule manuellement pour parer à un éventuel nouveau défaut de l’automate.

Dans les prochains jours, nous allons réaliser le test en charge du site ce qui nous permettra de valider le bon fonctionnement de l’automate.


Pourquoi les tentatives de démarrage des groupes HT ont-elles échoué ?
----------------------------------------------------------------------
Le datacentre SBG2 est alimenté avec 2 groupes électrogènes BT de 1.4MVA chacun. L’un de ces 2 groupes BT était en « mode maintenance ». En « mode maintenance », dans le cas d’une coupure électrique, les 2 groupes électrogènes HT de SBG1 fournissent l’énergie à SBG2, à la place du groupe électrogènes BT en maintenance.

Jeudi le 9 novembre, lorsque que le site a été privé d’énergie, l’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas donné l’ordre de démarrage aux groupes HT.

Nous avons donc procédé à des tentatives de démarrage manuelles.

Pour faire fonctionner la charge électrique de SBG1, SBG4 et SBG2 avec l’un des deux groupes BT en « mode maintenance », il faut absolument que les 2 groupes HT fonctionnent ensemble afin de fournir 4MVA. Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparèment. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.


Combien de temps a-t-il fallu pour rétablir les services ?
----------------------------------------------------------
Des moyens exceptionnels ont été mis en place afin de rétablir au plus vite les services.


État des lieux général :
------------------------
Jeudi à 22 heures, 97 % des serveurs (hardware) étaient de nouveau fonctionnels ainsi que 91 % des services (software). Vendredi à minuit, 99 % des serveurs étaient de nouveau opérationnels ainsi que 96,2 % des services.

Dans le détail :

Private Cloud :
----------------
Jeudi 9 novembre
·       23h : 78,59% des vCenters opérationnels

Vendredi 10 novembre
·         5h : 100% des vCenters opérationnels


Object Storage/Cloud Archive :
-------------------------------
Jeudi 9 novembre, 13h35 : 100 % opérationnel


PCS :
-----
Jeudi 9 novembre, 13h35 : PCS/PCA 100% opérationnel

PCI/VPS* : (*zoning PCI : les « régions PCI » ont une nomenclature différente de celle des datacenters)
------------------------
11h30 : API est UP sur le région SBG1/SBG2/SBG3
17h : 98% instances OK région SBG3
20h00 : 98% instances OK région SBG1
21h00 : 92% instances OK région SBG2

Vendredi 10/11
16h00 : 100% instances OK région SBG1
16h30 : 100% instances OK région SBG2

Samedi 11/11
18h : 100% instances OK région SBG3


SD :
----
Jeudi 9/11
21h : 93,05% des serveurs dédiés sont opérationnels

Vendredi 10/11
17h : 99,1% des serveurs dédiés sont opérationnels


Comment avez-vous géré la situation ?
--------------------------------------
Dès 7 h 50, une cellule de crise est activée à Roubaix afin de coordonner toutes les actions des équipes. Octave Klaba, le CEO et fondateur d’OVH, rend compte de l’évolution de la situation en temps réel, via les réseaux sociaux. Des explications détaillées sont aussi fournies sur la tâche travaux.
 
En parallèle, les équipes support françaises s’organisent avec leurs homologues québécoises pour répondre à un maximum de sollicitations. Les clients Grands Comptes concernés sont contactés afin de leur apporter des solutions rapides et concrètes.
 
À Strasbourg, les équipes datacentres sont vite renforcées par des techniciens venus de nos centres de données allemands (Francfort) et français (Roubaix). Un véritable pont routier et ferroviaire est mis en place. Vers 17 h 30, un camion de 38 tonnes provenant du centre logistique d’OVH en métropole lilloise, leur apporte toutes les ressources matérielles additionnelles nécessaires pour les heures à venir. Plusieurs camions arriveront les jours suivants, suite à la mise en place d’une astreinte logistique à Roubaix.

Ces équipes ont ainsi travaillé sans relâche, nuit et jour, pour rétablir les services de tous les clients, allant jusqu’à justifier l’organisation et la mise en place d’un pont aérien entre Lille et Strasbourg afin d’accélérer les rotations des équipes présentes sur place durant le week-end et toute la semaine.


Quel est le plan d’action mis en place suite à cet évènement ?
---------------------------------------------------------------
Comme évoqué précédemment, nous avons immédiatement pris des mesures pour proscrire ce type d’incident à Strasbourg (SBG) ainsi que sur l’ensemble de nos sites.

Ce plan d’actions va se déployer en 2 phases.

À court terme
-------------
Nous avons demandé un rapport détaillé au fournisseur de l’automate.

Puisque le basculement de l’automate normal/secours motorisé n’a pas fonctionné, nous avons une présence dédiée 24 heures sur 24 et 7 jours sur 7, afin de pouvoir réaliser manuellement la manœuvre en cas de non-fonctionnement de l’automatisme. Cette astreinte sécurise le site en attendant qu’un test en charge puisse confirmer le bon fonctionnement de l’automate.

Pour la partie inverseur normal/secours, nous allons rapidement remplacer la partie automatisme par un automate « maison », qui nous permettra d’en maîtriser complètement le fonctionnement et de le monitorer. Un système identique est déjà en production à Gravelines.

Nous avons demandé un rapport détaillé à ESR concernant l’origine de l’avarie.

Une étude de faisabilité concernant le raccord d’une deuxième arrivée électrique de 20MVA est également lancée. En attendant, nous avons lancé une 2eme étude : la mise en place de 2 disjoncteurs isolés, un par câble, ce qui permettrait de secourir un éventuel défaut sur l’un des 2 câbles.

Nous allons effectuer la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4 ainsi que la séparation du futur SBG3, vis-à-vis de SBG2 et SBG1/SBG4. De cette manière, chaque datacentre disposera de son alimentation de secours indépendante.

Un audit électrique est également en cours pour l’ensemble de nos sites.

À noter : à l’heure actuelle, lorsqu’un serveur est commandé sur le site de Strasbourg, il apparaît par défaut au sein de l’espace client comme hébergé au sein de SBG1, même s’il est hébergé à SBG2 ou SBG4. C’est un bug d’affichage. Cette anomalie sera corrigée très rapidement afin de laisser apparaître le datacentre réel au sein duquel le serveur est hébergé.


À long terme
------------
La technologie basée sur les containers maritimes ne sera plus utilisée par OVH. En effet, elle n’a été utilisée que pour construire SBG1 et SBG4, et hérite des imperfections de design liées à la faible ambition initialement prévue pour le site. Aujourd’hui, nous réalisons qu’elle n’est plus adaptée aux exigences de notre métier et aux normes OVH. Nous allons donc démanteler SBG1 et SBG4.

Pour cela, une migration de l’ensemble des services de nos clients hébergés sur SBG1 et SBG4 sera opérée vers SBG2 et SBG3 ou sur d’autres datacentres OVH.


Nous sommes sincèrement désolés pour cette panne et nous faisons le nécessaire afin que ce type d'incident ne se reproduise plus.

Amicalement
Octave


vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
Par contre sous l'eau effectivement ce n'est pas garantie! La question est donc est-ce l'eau qui a fait cramer les onduleurs ? ou est-ce l'incendie qui a fait  fondre le système de refroidissement!?
La hausse de l'humidité, c'est 1h20 avant les départs de feu, c'est pour cela que c'est intrigant.

Peut-être que c'est une erreur de mesure, mais une fuite du circuit de refroidissement est un incident qui est possible. Après reste à comprendre si la fuite d'eau a pu avoir un impact sur l'automate de l'onduleur.


Les batteries des onduleurs peuvent être victimes d'emballement thermique (suite problème de clim?) et normalement les onduleurs savent gérer ce problème, cela n'aurai t pas du arriver.

L’emballement thermique peut provoquer une hausse de la tension de manière importante ?

J'ai pensé de mon coté que des défauts sur une batterie ne pourrait provoquer l'incendie de l'onduleur.

Je pense que l'inverse est plus plausible : L'incident sur l'onduleur ont fait que des tensions et intensités anormales ont été appliquées aux batteries et la plus faible du lot à pris feu.

Un incident logiciel peut-il être la cause d'un comportement suicidaire de l'onduleur ?

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
La vraie question c'est quand même : quelle est la marque des onduleurs?, Est-ce qu'il y a des logs?

L'onduleur en question est un onduleur PS7, qui a eu une maintenance le matin du drame avec de nombreuses pièces changées.

OVH avait partagé ces éléments dés le lendemain de l'incendie, avant même d'avoir accès aux images de vidéosurveillance qui ont confirmé la chose.

Extrait des conversation du lendemain de l'incendie :

Alors... les onduleurs standards, c'est des batteries au plomb, pas au Li-Ion.
De plus, dans la majorité des datacenters, les onduleurs sont dans le même bâtiment que les serveurs.
Mais pas localisés dans la même salle. Et les salles onduleur sont normalement suffisamment bien isolées avec des murs résistants au feu.
Dans le Datacenter OVH SBG2, les salles TGBT+ onduleurs étaient dans des salles au rez de chaussée, dans une construction "en dur". Les le reste du bâtiment, où sont hébergés les serveurs, c'est de la construction légère préfabriquée.
Mais est-ce que ces salles onduleur étaient avec des parois résistantes au feu? Et dispositifs d'extinction incendie actif à l'intérieur? Je crois que personne ici n'a l'information, et pas certain qu'on le sache un jour.

Leon.

Donc on le sais aujourd'hui, le plafond au-dessus de l'onduleur en feu était en bois brut ayant subi un traitement intumescent "traitement coupe-feu 1 heure par application de peinture intumescente ou de flocage" (cf schéma des pompiers). Cela explique la propagation rapide, sachant, que le départ de feu était à 0h35 et que Strasbourg Électricité Réseaux a coupé le 20 000 volt à 1h50 et que donc les pompiers n'ont pas pu intervenir les 75 premières minutes au moins (le rapport n'est pas clair sur le moment où les pompiers ont commencé à arroser le bâtiment, sachant que à 2h14, il y a toujours du courant dans le bâtiment SBG2, a cause des batteries + onduleurs de la salle d'énergie N°1 qui n'avait pas encore brûlée étant au rez-de-chaussé de l'autre coté de SBG2.

(cliquer sur l'image pour zoomer)

vivien

  • Administrateur
  • *
  • Messages: 47 183
    • Twitter LaFibre.info
On avait aussi alf084 qui avait identifié un technicien de Vertiv, société spécialisé dans les onduleurs, dans les vidéos postées par Octave suite à l'incendie :

Était-ce un onduleur VERTIV impliqué dans l'incendie ? Le technicien est bien identifiable avec une casquette du constructeur sur la tête. (Video d'Octave)




La vidéo en question, le technicien Vertif apparaît à la 28ème seconde de la vidéo :
Nouvelle vidéo d'Octave Klaba incluant quelques photos des travaux :

L'origine du sinistre se concentre sur l'onduleur et les batteries, une nouvelle vidéo avec plus de détails sur l'origine sera tournée vendredi prochain.




bco_

  • Abonné Orange Fibre
  • *
  • Messages: 16
Empiler des boites : bon ce n'est pas non plus l'idéal.

En soit, le feu s'est propagé dans SBG1 par des portes coupes feu qui sont restés ouvertes de ce que j'en comprends ( CF P31 ) :

> Les services de secours nous ont toutefois rapporté que des portes coupe-feu avaient été maintenues ouvertes au moment de l’évacuation, ce qui a eu pour effet de dégrader l’efficacité de ce dispositif.

Bon par contre, pour moi dans un bâtiment qui n'est pas un ERP, une porte coupe feu est sensé être fermé tout le temps. A contrario d'un ERP où elle est collée à une ventouse qui se coupe en cas d'incendie.


Damien

  • Expert
  • *
  • Messages: 1 917
Merci Vivien pour ce fil très intéressant qui m'a permis d'occuper une partie de mon insomnie 😁