Política de Cookies
Utilizamos cookies propias y de terceros para mejorar tu accesibilidad, personalizar y analizar tu navegación. Al continuar navegando consideramos que aceptas su instalación. Puedes cambiar la configuración u obtener más información en nuestra
(+ info)

Aceptar

PQC

Pérdidas de disponibilidad de los data centers de 2023

POSTED BY Garcerán Rojas 19 de diciembre de 2023

Los sucesos de pérdida de disponibilidad, en este año, han discurrido según unas cifras similares a las de años anteriores (quizá ligeramente por debajo), pero, en cualquier caso, son lo suficientemente numerosos como para poder sacar algunas conclusiones claras.

Alo largo de todo el 2023, hemos continuado muy atentos a todo lo sucedido en estos data centers de nuestras entretelas y, como siempre, de forma muy particular, a todo lo concerniente a la disponibilidad o, mejor dicho, a su ausencia. Los sucesos, en este año, han discurrido según unas cifras similares a las de años anteriores (quizá ligeramente por debajo), pero, en cualquier caso, son lo suficientemente numerosos como para poder sacar algunas conclusiones claras.

De todo lo que se ha publicado, que no ha sido poco, podemos extraer una serie de patrones cuya reiteración resulta bastante manifiesta, por no decir machacona, no sólo por su presencia en 2023 sino por su continuidad, desde hace ya demasiado tiempo, en el anuario de los despropósitos más aclamados.

Pérdidas de disponibilidad más recurrentes

Los pérdidas de disponibilidad más recurrentes siguen teniendo que ver con el suministro eléctrico y, dentro del mismo, con la no actuación de los sistemas de respaldo y/o la incapacidad para poderlos poner en marcha, pero durante los últimos meses, se ha añadido el incendio como causa primaria del problema. Sin llegar a la extensión de lo ocurrido con OVH, Cyber1 o Maxnod, pero con una multiplicación alarmante en el número de casos y una asociación, cada vez más evidente, con el mundo de las baterías como el último caso que se ha conocido en Chandigarh, al norte de India, donde el fuego iniciado en el recinto de baterías de los UPS del data center afectó a una buena parte del hospital al que pertenecía.

Además, hemos de significar un nuevo ingrediente de pérdida de disponibilidad, como es el hecho de que los problemas que derivan en la pérdida del servicio hayan elegido la noche como acompañante, tiempo durante el cual el personal de operación y mantenimiento suele encontrarse en situación algo precaria, tanto en número como en experiencia y formación, como si la importancia del servicio en esa franja horaria fuese menor, una especie de 24×7 a lo “Gruyère”.

Por otra parte, sigue demostrándose que los errores humanos se encuentran en la base de una importante proporción de caídas, así como el hecho de que existen lugares comunes en los que refugiarse a la hora de tener que dar explicaciones, como los de los ya famosos “pico de tensión” o “golpe de calor” que, de tanto como se han utilizado, ya nadie se los cree cuando resultan ciertos.

Por último, y como mención especial, merece la pena hacer alusión a las conocidas como “zonas de disponibilidad”. Esa suerte de combinación de, normalmente, tres data centers, cuya resiliencia combinada o híbrida debe preservar el servicio ante posibles incidencias en cualquiera de ellos, incluso la caída completa. Ya son unos cuantos los casos de pérdidas de disponibilidad en ese tipo de escenarios, cuya responsabilidad suele encontrarse atribuida a fallos encadenados o consecuenciales que a nadie se le había ocurrido ensayar previamente.

Un caso con todos los ingredientes

Pero la guinda de este pastel es un caso que, realmente, reúne todos los ingredientes de pérdidas de disponibilidad en un solo producto. Ha tenido lugar durante el mes de noviembre en un importante data center situado en el estado de Oregón y, según lo publicado por los responsables del lugar, pudo suceder según la siguiente cronología de acontecimientos.

  1. Empresa de servicios IT con sus sistemas alojados en tres data centers, presumiblemente en activo-activo, pero con determinados servicios críticos sin “subir” al cluster de alta disponibilidad.
  2. Pérdida de una de las líneas de suministro de red eléctrica exterior. El resto de líneas permaneció activo, teniendo capacidad suficiente para alimentar la totalidad del data center.
  3. Arranque de los grupos electrógenos, también con capacidad suficiente para alimentar todo el conjunto de la instalación.
  4. Ausencia de comunicación por parte de la empresa operadora del centro a su cliente, lo que impidió que éste pudiera establecer ningún protocolo de actuación.
  5. Conexión simultánea de grupos y red exterior como sistema de suministro. Posible situación especial al tener la empresa un contrato con la compañía suministradora para poder utilizar sus grupos como apoyo de la red en situación de alta demanda general.
  6. Aparición de una falta a tierra en una de las líneas de media tensión que provoca la actuación de, al menos, una protección común para la parte de red y la de grupos (¿posible ausencia de selectividad?).
  7. Suministro ininterrumpido a cargo de UPSs con una autonomía teórica de 10 minutos que permitiría un cierto margen de actuación para reponer el sistema de respaldo. Tiempo escaso pero suficiente si la actuación es rápida.
  8. Control de accesos sin alimentación ininterrumpida. Dificultades para alcanzar los lugares de intervención.
  9. Horario nocturno, con limitaciones en cuanto al número de especialistas en servicio y a la experiencia y formación de éstos.
  10. Agotamiento de las baterías a los 4 minutos. Caída del sistema.
  11. Intento de rearme de las protecciones y situación defectuosa de las mismas (original o como consecuencia de la última apertura). Cargas de trabajo transferidas progresivamente a otros centros, pero tiempo local de reposición extendido con una duración total del evento por encima de las 40 horas.

Decía el maestro Ken Brill que los fallos catastróficos nunca son el resultado de una sola cosa sino, más bien, de la interactuación de entre 5 y 10 (típicamente 7), y este caso no puede suponer un ejemplo mejor. Explicarlo parece “recochineo”. Ken, sin duda, se quedó corto.

De verdad que se echa en falta en las organizaciones la simulación del caos como método de ensayo (introducción de escenarios de fallo) para la comparación entre lo que piensas que ocurrirá en tu sistema ante determinados supuestos y lo que realmente ocurre.

En definitiva, seguiremos atentos a lo que vaya sucediendo por ahí. Y, como realmente resultaría una quimera pretender que todos estos casos desaparezcan de un plumazo, nuestro deseo más alcanzable es que, como mínimo, dejen de sorprendernos tan habitualmente.

-

Este artículo de opinión ha sido redactado por Garcerán Rojas y publicado originalmente en la revista DataCenterMarket

Garcerán Rojas