Hace ya más de un año que el centro de datos SBG2 de OVHcloud en Estrasburgo fue destruido por un incendio. Las disputas legales sobre la responsabilidad y la compensación continúan, y todavía no hay un veredicto público oficial sobre lo que realmente sucedió.

Esto no debería ser una sorpresa. El sector de los centros de datos es sorprendentemente malo para informar de manera transparente lo que sucede durante los incidentes. Para tomar un ejemplo, cuando los centros de datos de British Airway fallaron en 2017, perdió 75 millones de dólares en negocios durante un fin de semana festivo. Cualquier esperanza de que alguna vez nos dijeran lo que sucedió se desvaneció rápidamente. BA y su socio de centro de datos CBRE acudieron a los tribunales, culpándose mutuamente. Dos años después, llegaron a un acuerdo financiero secreto en el que ninguno admitió culpa alguna.

En algún momento, el director ejecutivo de BA, Willie Walsh, admitió tímidamente que hubo un "error humano". Y eso fue todo lo que escuchamos.

No es lo suficientemente bueno

A menudo se comenta que si uno de los aviones de BA se hubiera estrellado, habríamos obtenido rápidamente los resultados del registrador de la "caja negra", siguiendo un procedimiento claramente definido. No existe tal procedimiento en el mundo de los centros de datos, a pesar de los valientes esfuerzos para establecer iniciativas como DCIRN (la Red de Informes de Incidentes de Centros de Datos, que ha estado un tanto tranquila últimamente).

Y los comentaristas han señalado regularmente que, sin informes completos sobre las causas del fracaso, esta industria está condenada a repetirlos.

¿Qué probabilidades hay de que el desastre de OVHcloud siga una trayectoria similar de secretismo?

Para su crédito, inmediatamente después del incidente, el proveedor de la nube francés fue comparativamente abierto sobre el incidente. En los días posteriores al desastre, el fundador de OVHcloud, Octave Klaba, y el director ejecutivo, Michel Paulin, realizaron una serie de videos. Klaba reveló que el incendio se apoderó de los sistemas UPS de SBG2 y habló sobre la actualización de la estructura de la nube de la empresa para proporcionar el tipo de zonas de disponibilidad disponibles en AWS.

La compañía emitió actualizaciones públicas sobre el proceso físico de limpieza y reconstrucción de sus servicios. Detallaba qué compensación recibirían los clientes y prometía financiar un laboratorio dedicado al estudio de la prevención de incendios .

Clamándose

Luego, en mayo, se cerró. La compañía anunció que no podría revelar la causa del incendio hasta 2022. Estamos a casi un cuarto de 2022, no hay señales de un informe y OVHcloud no ha dado ninguna fecha para el informe. La explicación de la empresa es que tiene las manos atadas. Aparentemente, no puede decirnos qué causó el incendio hasta que se aclaren los detalles con sus aseguradoras y agencias gubernamentales.

Para poner esto en contexto, hemos estado esperando más de un año, y eso es mucho tiempo para un informe de interrupción que no enfrenta el tipo de disputas que oscurecieron la interrupción de BA. La participación del gobierno no tiene por qué ralentizar las cosas: cuando una falla en noviembre de 2017 provocó una interrupción de tres horas en la Bolsa de Valores de Singapur (SGX), el gobierno de Singapur estuvo involucrado, pero el informe se entregó a SGX en cuatro meses (marzo siguiente) , y publicado en siete.

Es difícil no sentir que OVHcloud simplemente preferiría cambiar de tema y olvidarse del incidente.

Desde entonces, Octave Klaba no ha dicho nada más sobre el incidente. Ha estado ocupado desarrollando un negocio de juegos, mientras que OVHcloud ha preferido hablar sobre los nuevos servicios que parece lanzar a un ritmo cada vez mayor, incluida una nube privada basada en Nutanix , un servicio PaaS, un servicio de almacenamiento de objetos y nuevos servidores bare metal.

Esta semana ha trascendido la noticia de que OVHcloud está implicado en una acción antimonopolio contra Microsoft. La acción ha estado en marcha desde septiembre del año pasado y argumenta que Microsoft está abusando de su posición en la nube, donde es fuerte, pero no el jugador dominante. Hay varias partes involucradas, pero OVHcloud es el único que rompe el silencio al respecto.

Es fácil sospechar que OVHcloud quiere ganarse el favor de un jugador europeo y distraer a los clientes del problema del incendio sin resolver. Sin que nadie hablara del incendio, su salida a Bolsa en octubre fue muy buena para la compañía.

Pero un pequeño detalle surgió durante la oferta pública inicial. Se espera que el incendio le cueste a la empresa unos 105 millones de euros, según documentos legales. Esta cifra podría cambiar fácilmente, por supuesto, dado que la causa y las implicaciones del incendio aún no están determinadas. También hay reclamaciones no resueltas de los clientes.

Acción de clase

Algunos clientes no están dejando pasar el problema. El bufete de abogados de París Ziegler & Associates está presentando una demanda colectiva que afirma que OVHcloud está eludiendo su responsabilidad y debería ofrecer una mejor compensación para cubrir la pérdida de datos y el impacto comercial que sienten los clientes. En respuesta, OVHcloud dice que el incidente estaba fuera de su control y que los clientes deberían haber sabido que sus servidores estaban respaldados en el mismo sitio, si es que lo estaban.

Gran parte de la defensa de OVHcloud, cuando la entregue por completo, se basará en un informe de incendios detallado, que todavía no tenemos.

En el último conteo, 130 clientes habían firmado para la acción, en la que Ziegler especificará las solicitudes de daño de cada uno. Este mes, el bufete de abogados ha retrasado una vez más la entrega definitiva de las reclamaciones de sus clientes a OVHcloud, porque todavía se están incorporando más clientes de OVHcloud.

¿Qué sabemos?

En este momento, ¿Qué sabemos realmente sobre el incendio?

El incendio estalló a las 00:40 horas del 10 de marzo. Se necesitaron seis horas para que 100 bomberos lo controlaran, utilizando 44 vehículos de extinción de incendios. Los bomberos franceses fueron ayudados por un barco bomba franco-alemán en el Rin.

Antes del incendio, SBG2 era un centro de datos de cinco pisos y 500 metros cuadrados. Después, fue una ruina. Otros tres centros de datos en el mismo sitio también se vieron afectados.

El diseño de los centros de datos en el sitio de Estrasburgo había pasado por varias generaciones, comenzando con los contenedores de envío y abarcando cuatro centros de datos desde SBG1 hasta SBG 4 el día del incendio.

Un año después, un informe de los bomberos finalmente confirmó varios hechos sobre este incendio. Al parecer se inició en una sala de suministro eléctrico, donde los bomberos encontraron el UPS7 en llamas, con enormes arcos eléctricos de más de un metro de largo que impedían el acceso.

En los días posteriores al incendio, Klaba había revelado que UPS7 acababa de realizar trabajos de mantenimiento el día anterior al estallido del incendio. El 12 de marzo dijo: “El proveedor vino y cambió muchas piezas dentro de UPS7, y lo reiniciaron en la tarde. Parecía que estaba funcionando, pero en la mañana tuvimos el incendio”.

Los bomberos dicen que no pudieron ocuparse del incendio de la sala de energía de inmediato, porque no pudieron cortar la energía. Les llevó casi tres horas, hasta las 03:28, cortar la energía en el sitio. Durante este tiempo, el fuego se desató y las llamas se extendieron por el centro de datos.

Aparentemente, esa propagación fue acelerada por los suelos de madera del centro de datos, que se incendiaron. Estos suelos quizás no representaban un riesgo de incendio tan extremo como podría temerse, ya que los materiales de construcción de madera están diseñados para resistir el fuego. Pero la demora en apagar el incendio de la sala de energía debió haberlos empujado más allá de sus límites: los bomberos informaron que el techo de la sala de energía estaba clasificado para resistir el fuego durante solo una hora, y la falta de un interruptor de corte dejó la sala de energía en llamas. por más tiempo que eso.

Los bomberos observan que el centro de datos no tenía un sistema automático de prevención o extinción de incendios.

Finalmente, los bomberos describen que los dos patios del centro de datos actúan como una "chimenea" que aceleró el incendio.

Unos días después, el 20 de marzo, los bomberos tuvieron que regresar para atender otro incendio en una sala de baterías de UPS en el sitio. Otros señalaron que OVHcloud había estado reemplazando los cables de alimentación de UPS en varios de sus sitios.

El contexto

OVHcloud se niega a responder a estos detalles, alegando que todavía no puede hablar hasta que tengamos un informe formal (un informe más formal que la respuesta de los bomberos).

Esto nos deja recogiendo las observaciones de los bomberos que no son expertos en centros de datos, pero que se conectan con las críticas que surgieron durante el año.

Comenzando por la falta de un corte de energía, es cierto que los centros de datos están diseñados para que sea difícil apagarlos, por lo que los servicios siguen funcionando. Por ejemplo, se le ha dicho a DCD que es una práctica común no proporcionar un interruptor de corte obvio para los centros de datos, que podría activarse por error y provocar la caída de los servicios.

Sin embargo, obviamente es peligroso e incorrecto no tener ninguna forma de cortar la energía. En este caso, varios clientes de OVHcloud informaron que sus servicios continuaron hasta altas horas de la madrugada con un incendio que arrasaba el edificio.

Durante el año, un artículo en VO News de Clever Technologies afirmó que había fallas en el diseño de energía del sitio, por ejemplo, que la instalación vecina SBG4 no era independiente y obtenía energía del mismo circuito que SBG2. Está claro que el sitio tuvo varias generaciones, y entre su trabajo después del incendio, OVHcloud informó de la excavación de una nueva conexión eléctrica entre las instalaciones.

En 2017, después de un apagón, OVHcloud (entonces conocido como OVH) prometió retirar sus edificios basados ​​en contenedores y desmantelarlos, y separar las instalaciones en el sitio en fuentes de energía distintas y separadas. Los informes en ZDnet.fr y en otros lugares sugirieron que es posible que este trabajo nunca se hubiera completado. Se afirma que quedaron algunos elementos del contenedor de envío.

Otros elementos constructivos están siendo cuestionados. Los primeros comentarios de los bomberos dijeron que la presencia de madera y plásticos empeoró el fuego. Sabemos con certeza que había pisos de madera, y el informe del incendio confirma que se quemaron.

La mención de los bomberos de un efecto "chimenea" también es interesante. Antes del incendio, OVHcloud estaba muy orgulloso de su diseño de cinco pisos, en el que la convección natural proporcionaba circulación de aire para enfriar los servidores. Es posible que esto haya acelerado el fuego.

Tanto Clever Technologies como ZDnet.fr afirman que SBG2 no tenía un sistema automático de extinción de incendios. La única respuesta de OVHcloud ha sido su promesa hace un año de montar un laboratorio para investigar las mejores prácticas en la prevención de incendios en los centros de datos.

Pero ya existen muchas mejores prácticas establecidas para la detección y la prevención, incluido el uso de gases inertes para sofocar un incendio sin crear cortocircuitos eléctricos. En algún momento, necesitaremos saber si OVHcloud los estaba siguiendo.

Tiempo de respuesta

Más allá de eso, los clientes tuvieron problemas con el servicio de OVHcloud y han dicho que la letra pequeña no dejaba claro si se hacía una copia de seguridad de los datos o no, y dónde se guardaban esas copias de seguridad. Algunos servicios se respaldaron en máquinas en el mismo edificio, por lo que los clientes perdieron sus datos cuando se destruyó el edificio.

Está claro que OVHcloud ya conoce la causa de este incendio. Ocurrió en una instalación más antigua que se construyó de acuerdo con diseños que ya no usa y que estaba en mantenimiento y mejoras.

Sin duda, esperamos y confiamos en que OVHcloud esté aplicando las lecciones aprendidas del incendio. Sería bueno que otros también pudieran aprender.

Es injusto para los clientes y colegas de la industria mantener estos detalles en privado.

Por Peter Judge, Editor global de DatacenterDynamics