[bws_linkedin display=»share»]

Una vez transcurrido el parón veraniego, volvemos a la carga con la serie de artículos sobre el Performance Indicator. En esta ocasión, hablaremos del tercer indicador: el Thermal Resilience.

Los responsables de sistemas y/o directores de TI saben que, en la mayoría de sus casos, su cuello depende de que los sistemas funcionen: no me cuentes historias, haz que funcione y haz que funcione ya! Por eso muchos tienen una palabra en la cabeza: redundancia. Es evidente que cualquier dispositivo puede fallar, así que hay que tenerlo redundado por si las moscas. Durante la época de las vacas gordas, y más en los ochenta y noventa, en los que la informática era la estrella de la organización, esto no era un problema. Hay directores de sistemas que, como el coche tiene cuatro ruedas, llevan cuatro ruedas de repuesto porque todo debe estar redundado. Ya dedicaremos alguna entrada del blog a redundancia y sus conceptos básicos, pues tiene mucha más enjundia de la que parece y hay bastante gente que no lo tiene claro.

La definición intuitiva del Thermal Resilience es la capacidad para hacer frente a problemas en el sistema de refrigeración, y mucha gente interpreta que esta capacidad es igual a redundancia. Pero (volvemos al concepto de redundancia) el error es pensar que lo único que tenemos que tener en cuenta en nuestra redundancia son los posibles fallos en el sistema de climatización. No, esto no es así. Nuestra resistencia a fallos varía en el tiempo en función de las condiciones de explotación, y esto es lo que mide el Thermal Resilience.

Para simplificar las cosas y entenderlo fácilmente vamos a poner un ejemplo sencillito. Supongamos que tenemos un CPD clásico, con refrigeración por falso suelo, en el que tenemos tres CRAC’s repartidos por la sala. Si cada uno de ellos tiene una capacidad de refrigeración de 50kW, tendremos una capacidad total de 150kW. Si la carga en un momento dado es de 45kW, se tendrá una redundancia N+2: podrán fallar dos CRAC’s y, en teoría, no habrá problemas (en teoría, porque en la práctica depende de cada sala concreta, ver el apartado de Thermal Conformance). Resulta que, en el momento en el que un CRAC había fallado y otro estaba fuera de servicio por revisión, los del departamento financiero (siempre tienen el don de la oportunidad) habían lanzado un proceso de business inteligence con unos cubos OLAP enormes, los sistemas se pusieron a tope y la carga había subido a 75kW. Así que en ese momento puntual tenemos 50kW de capacidad frigorífica para hacer frente a una carga de 75kW, por lo que tendremos problemas sí o sí.

Este ejemplo era muy sencillo. En realidad, el sistema de refrigeración es un mecano complejo y más en la actualidad, en el que es fácil encontrarse simultáneamente CPD’s que disponen de más de un sistema de refrigeración y que cada uno de ellos tenga n componentes. Por ejemplo, por un lado puede haber free cooling directo  y por otro un sistema basado en agua en el que haya enfriadoras de agua en el exterior e intercambiadores de calor en la sala. La capacidad de refrigeración del freecooling directo dependerá de la temperatura exterior, y la del sistema de agua dependerá de si funcionan todas las enfriadoras y todos los intercambiadores.

Por otra parte, lo hemos dicho una y mil veces, la carga es dinámica. Lo es por dos factores, y el primero de ellos es elemental: a lo largo del tiempo instalamos servidores y equipos y los damos de baja. Tenemos nuestro flamante CPD recién construido y estrenamos el sistema de refrigeración, que estará diseñado para tener una determinada redundancia a una determinada carga nominal. Si sólo instalamos un servidor tenemos una redundancia enorme y a medida que vamos instalando servidores la carga aumenta y la capacidad para hacer frente a problemas baja. El segundo factor es menos tenido en cuenta y es que la carga de los sistemas es dinámica, varía (y puede hacerlo mucho) en función de las condiciones de explotación. Los que nos dedicamos a la supercomputación lo sabemos muy bien, el consumo de los servidores prácticamente se triplica cuando ponemos los procesadores a tope. Un clúster HPC de 250 nodos consumirá unos 40kW encendido y con el sistema operativo cargado, pero su consumo se triplicará en cuanto le soltemos un sistema de ecuaciones medianamente puñetero: nuestro consumo habrá subido a 120kW y, si ese clúster está instalado en la hipotética sala que hemos mencionado antes ¡habremos pasado de tener redundancia N+2 en el sistema de refrigeración a no tener redundancia por el simple hecho de lanzar un programa a nuestros servidores!

Esto es, precisamente, lo que mide el Thermal Resilience. En la entrada anterior definimos el Thermal Conformance como el porcentaje de carga al que le está entrando el aire a temperatura correcta. Bueno, pues la definición que hace TGG del Thermal Resilience es el porcentaje de carga al que le entra aire a temperatura admisible en el peor caso de fallo del sistema de refrigeración. Esto requiere definir dos cosas: qué es temperatura admisible y qué es peor caso del sistema de refrigeración:

IT Thermal Resilience = Eq Load (T_inlet < 32º under worst case cooling failure) / Total Eq. Load

Como se ve en la fórmula, el propio TGG propone 32º como temperatura admisible. Pero lo difícil es definir  qué es el peor caso de fallo del sistema de refrigeración. En el ejemplo de antes, en el que había un sistema de refrigeración sencillo con tres CRAC’s, es que fallen dos. De los tres indicadores que forman el PI es el más difícil de calcular, pues hoy en día las configuraciones son complejas, y el concepto peor fallo del sistema de refrigeración puede ser difícil de precisar. Así que, como siempre, si tenéis dudas consultad.

En el próximo artículo hablaremos de la verdadera potencia del PI: cómo los tres indicadores tiran unos de otros, es decir, cómo están relacionados para consigamos en nuestro datacenter el mejor equilibrio entre eficiencia, redundancia y fiabilidad.