Seleccionar página

Performance Indicator (V): Thermal Resilience

martes, 5 Sep PM | Datacenter, Eficiencia Energética, Green Grid, Métricas

[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 (Tinlet < 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.

 

 

 

 

 

Performance Indicator (IV) – IT Thermal Conformance

martes, 25 Jul PM | Datacenter, Eficiencia Energética, Green Grid, Métricas

[bws_linkedin display=»share»]

Hoy toca hablar del segundo indicador del PI: el Thermal Conformance, es decir, cumplimiento térmico. Pero ¿qué quiere decir cumplimiento térmico?

Los que visitáis con frecuencia CPD’s habéis comprobado que en ellos hace frío. En alguna conferencia hemos contado que una de las razones para que esto sea así es histórica: los viejos mainframes de los setenta y ochenta consumían poco y por tanto el coste de refrigeración era una fracción ínfima respecto al coste de explotación del bicho, así que era necesario crearles una aureola esotérica, y para eso el frío ayuda mucho: el mainframe se encontraba en un altar de condiciones muy especiales, empezando por el frío. Así que, tradicionalmente, en los CPD’s ha hecho excesivo frío. Los sistemas deben estar en el rango de temperatura especificado por el fabricante: no más, pero tampoco es necesario que esté a menos, ya que en este caso ni va a funcionar mejor ni más rápido.

Gracias a que algunos hemos dado mucho la tabarra con este tema, mucha gente se ha dado cuenta de que la temperatura del CPD tiene una influencia decisiva en la Eficiencia Energética. Hace unos años esto importaba un pimiento a la mayoría de la gente: al director de TI lo único que le interesaba es que los sistemas funcionaran, y le daba igual si gastaba mucha electricidad o poca. Normalmente ni se enteraba del coste de la electricidad, pues son otros departamentos los que se ocupan de ellas (¡grave error, querido Watson!).

Sin embargo, ahora esto ya no es así: entre que aprieta la piedra al zapato de la pasta, aprieta la piedra al zapato de la ecología y aprieta la piedra al zapato de la Eficiencia, ya no hay quien de dos pasos sin ver si puede hacer algo para mejorar la Eficiencia y, por tanto, las facturas a pagar por la organización, el medio ambiente, la emisión de CO2, la imagen del departamento… Es más, recuerdo una anécdota personal. En las jornadas del Proyecto de e-Ciencia en Andalucía celebradas en 2007 hablé sobre Eficiencia Energética y TIC… y la audiencia se me dormía. Como me precio de ser un conferenciante capaz de captar la atención de la audiencia, me sorprendió. Así que en la celebración de esas mismas jornadas dos años después hice la misma charla con una pequeña modificación: donde ponía kWh cambié a Kg de CO2. Es decir, averigüé cuánto CO2 había que emitir a la atmósfera para generar un kWh según el mix energético de aquel año. A partir de ahí, hice la misma presentación, pero hablando de toneladas de CO2 emitidas a la atmósfera en vez de kWh que es un concepto aburrido. Como todos llevamos un ecologista dentro, la charla fue un éxito.

No hay que ser un genio para darse cuenta que el coste de refrigeración tiene un impacto enorme en la explotación de un CPD. En el pasado sólo preocupaban las consecuencias de un posible problema en la refrigeración. Pero hoy, además de eso, nos preocupa su coste. En un CPD legacy, puede pegarse un recorte significativo a los gastos de refrigeración a base de buenas prácticas, sin realizar apenas inversiones: distribuir correctamente las cargas, separar zonas frías y calientes y, la más importante de todas, tener una temperatura correcta. Es por eso que muchos responsables de explotación han añadido una palabra a su vocabulario: setpoint. Vamos, algo tan tonto como la temperatura de consigna del sistema de refrigeración, que en el pasado la programó el instalador y nunca se cambió. Ahora hemos aprendido que la podemos cambiar, es más, que la debemos subir y que para eso los fabricantes de los servidores hacen recomendaciones. No sólo los fabricantes, instituciones como ASHRAE hacen recomendaciones sobre cuál debe ser la temperatura de consigna en un CPD.

Pero hay que tener en cuenta un factor muy importante (y aquí vamos al meollo del Thermal Conformance): una cosa es la temperatura de consigna del sistema de refrigeración y otra diferente es la temperatura a la que el aire entra al servidor correspondiente. Es fácil ilustrar este concepto viendo la siguiente foto:

Muchos, en casa o en la oficina, tendréis algo así. Y habréis sufrido las discusiones: el que está sentado en el sofá debajo del split de aire acondicionado se quejará de que tiene exceso de aire frío en el cogote, pero el que está sentado al otro lado de la habitación se quejará de que pasa calor ¿A cuántos os pasa esto mismo en la oficina?. Es decir, yo he programado una temperatura de 24º al aparato, pero esto no quiere decir que consiga que toda la habitación esté uniformemente a 24º.

Bueno, pues en nuestro CPD pasa esto mismo. Pasará en mayor o menor medida en función del tipo de sistema de refrigeración, distribución de las salidas de aire, etc., pero pasará. Así que supongamos que vamos haciendo caso de recomendaciones y ponemos un setpoint de 26º, es decir, lo que queremos es que el aire entre a 26º a nuestros servidores.

Entonces, si lo que queremos es que entre aire a 26º a nuestros servidores ¿lo estamos cumpliendo? O, mejor dicho, ¿en qué medida lo estamos cumpliendo? Esto es, exactamente, el Thermal Conformance: el grado de cumplimiento de la especificación térmica. Vamos a explicarlo fácil: supongamos que tenemos cuatro racks, y que en tres la temperatura del aire de entrada está por debajo del umbral especificado y uno en el que está por encima. Es cierto que en el 75% por ciento de los racks entra el aire a temperatura correcta, pero ¿qué carga representa? Imaginad que en los tres racks en los que la temperatura entra correcta hay pocos servidores y tienen una carga de 1000W cada uno, y en que entra la temperatura incorrecta tenemos un blade con una carga de 7000W. La realidad es que en este hipotético CPD con 10.000W de carga ¡el aire entra a temperatura incorrecta al 70% de la misma! Eso es, exactamente, el Thermal Conformance: el indicador que nos dice a qué porcentaje de carga le está entrando aire a temperatura correcta.

Por cierto, que el ejemplo puesto no es tan descabellado: conozco CPD’s que tenían un montón de servidores legacy, y que en algún momento de la historia han hecho un proyecto de consolidación (¡Bien!) y han sustituido 100 servidores por un flamante blade sobre el que se han virtualizado los servidores. Ese blade, cuando se compró, hubo que instalarlo en el rack que estaba libre, que estaba en un extremo de la sala y al que llega ya poco flujo de aire… Desde el punto de vista funcional, genial. Desde el punto de vista de la eficiencia, también, seguro que han disminuido consumo. Pero han creado un punto caliente que acabará generando problemas de fiabilidad al sistema de refrigeración y al propio blade. Porque, una de las consecuencias del Thermal Conformance, es que hay una correlación entre tasa de averías y temperatura de entrada de aire si esta es excesivamente alta. Por cierto, en este punto una colleja colectiva: cuando se instala un servidor en un rack vacío la tendencia es, por comodidad, instalarlo a la altura de los hombros… pero si el sistema de refrigeración es por impulsión de aire en el falso suelo, poco aire frío llega a la parte superior de los racks.

Como la recomendación de ASHRAE es impulsar entre 18-27º, la estandarización del cálculo del Thermal Conformance que nos hace TGG es:

IT Thermal Conformance = Eq Load (Tinlet < 27º) / Total Eq. Load

Donde Eq Load es la carga en kW de los equipos IT. Es decir, para calcular el Thermal Conformance tenmos que dividir el porcentaje de carga IT a la que le llega la temperatura por debajo de 27º  por el total de carga IT. Como es evidente, necesitamos medir las temperaturas a las que entra el aire en los equipos. La especificación de TGG dice que hay que poner tres sensores por rack: arriba, en medio y abajo.

Intentad hacer un mapa mental de vuestro CPD y pensad ¿cuál sería mi IT Thermal Conformance? Os aseguro que si tenéis un CPD con refrigeración por falso suelo os llevaréis sorpresas desagradables. Imaginad que implantáis un sistema de medida del Thermal Conformance y que el primer número que os sale es malo. Intuitivamente es fácil comprender que si intentáis mejorar el TC a base de fuerza bruta inmediatamente subirá el PUE ¿comprendéis ya por dónde van los tiros del “indicador triple”, es decir, el Performance Indicator? Lo seguiremos viendo en los próximos artículos. Y ya sabéis, si queréis montar un sistema de medida del Thermal Conformance o tenéis alguna duda… consultad conmigo!

 

Performance Indicator (III) – Cómo medir el PUE

martes, 18 Jul PM | Datacenter, Eficiencia Energética, Green Grid, Métricas, Uncategorized

[bws_linkedin display=»share»]

Hoy vamos a hablar de cómo medir el PUE. Como en los últimos años todo el mundo ha hablado hasta la saciedad del PUE puede parecer absurdo escribir un artículo sobre cómo medirlo. Pero no, os aseguro que no es absurdo: he comprobado personalmente que, aunque mucha gente hable del PUE, no sabe en realidad cómo debe medirse.

Esto es así porque mucha gente, en vez de hablar sobre mediciones reales, lo hace sobre estimaciones basadas en potencias nominales teóricas. La inmensa mayoría no es consciente de que el PUE real va a depender mucho de la carga y condiciones de explotación, de la misma forma que el consumo real del coche no se parece en nada al homologado, pues en el consumo del coche influirá la carga, la forma de conducción, tipo de carretera y un montón de factores más.

Medir el PUE no entraña ningún misterio ni dificultad. Lo único es que hay que tener claro es qué hay que medir y cómo hay que medirlo, y disponer de los medios técnicos para hacer las medidas.

Conceptualmente, The Green Grid define el PUE como el ratio entre la energía del DataCenter y la energía consumida por los equipos IT, es decir:

PUE = Total Facility Energy / IT Equipment Energy

Viendo la fórmula el concepto está clarísimo. Ahora, para realizar la medida de forma correcta hay que tener claras las respuestas a las siguientes preguntas:

  1. ¿Qué significa energía del DataCenter? ¿Es potencia activa o energía activa? ¿Y si es energía activa, de qué periodo es?
  2. ¿Dónde hay que tomar la medida consumo Total?
  3. ¿Dónde hay que tomar la medida consumo equipos IT.

Os puedo asegurar que, en función de cómo respondamos a esas preguntas, podemos obtener cifras de PUE muy dispares. Así que, para hacer las cosas bien, vayamos a las definiciones dadas por TGG.

Para entender mejor las cosas, empecemos por lo conceptualmente más fácil, que es el consumo de los equipos IT. El alcance es sencillo de determinar: servidores, sistemas de almacenamiento, componentes de red, etc. Pero ¿dónde realizamos la medida? Hay tres posibilidades:

  1. A la salida de la(s) UPS. Fácil en la mayoría de los casos, basta con que la UPS disponga de algún sistema de monitorización, normalmente SNMP. En este caso el consumo IT sería la suma de los consumos a las salidas de las UPS. Por ejemplo, si hay dos UPS, el denominador de la ecuación del PUE será la suma del consumo a la salida de las dos UPS.
  2. A la salida de las PDU’s. Para esto hace falta disponer de PDU’s monitorizables. Si no las tenemos, es posible instalar pequeños monitorizadores en cada una de las líneas que vayan a las PDU’s (lo podemos conseguir por unos con muy bajo coste por PDU, si queréis preguntadme). El consumo IT será la suma del consumo de todas las PDU’s. Como es obvio, es necesario que todas las PDU’s estén monitorizadas. Si tenemos diez PDU’s pero sólo monitorizamos ocho, estamos dejando de sumar dos en el denominador y el PUE que obtendremos será más alto del real.*
  3. A la entrada de los equipos IT: requiere que cada enchufe de cada equipo IT esté conectado a un enchufe inteligente que monitorice la energía. Puede hacerse también a bajo coste (preguntadme de nuevo).

Bien, ya sabemos dónde hay que medir los consumos de los equipos IT. La siguiente pregunta es qué hay que medir. Parece una pregunta tonta, pero no lo es. Lo que hay que medir es energía activa (kWh) como si fuera un simple contador eléctrico. He visto algunas instalaciones en las que se mide potencia activa y se realizan los cálculos para conseguir la energía activa. Esto sólo es fiable si la frecuencia de muestreo es alta, y por eso la especificación dice que hay que utilizar energía activa.

Si ya sabemos las respuestas a las preguntas ¿dónde hay que medir? Y ¿qué hay que medir?, la siguiente es el cuándo. Es decir, cuándo tenemos que tomar las medidas o, mejor dicho, cada cuánto tiempo tenemos que tomar las medidas. La respuesta básica a esta pregunta es lo más a menudo que sea posible. Lo ideal sería que pudiéramos tomar medidas cada cinco minutos o, en su defecto, cada cuarto de hora como en el sector eléctrico.

Lo que es muy importante es tener en cuenta que el PUE es un año de medidas. Es decir, si quiero dar una medida sencilla pero real del PUE, lo que tengo que hacer es poner un contador eléctrico para que mida el consumo total, otro para que mida el consumo IT, esperar un año, ver los kWh consumidos y hacer la división.

¿Por qué un año? Para que la medida sea real. Si realizamos un muestreo frecuente, podremos ver momentos en el que la medida del PUE es muy buena y otros en las que es muy mala. Es decir, si en vez de tomar un año completo tomo sólo una hora, por ejemplo entre las seis y las siete de la mañana de un día de invierno en el que todo el datacenter esté refrigerado mediante freecoling y además por casualidad tengo todos los equipos IT al 100% de carga… me saldrá un PUE buenísimo, pero no es un PUE válido. Pero son necesarias: estas medidas parciales del PUE nos serán muy útiles para aprender las diferentes condiciones de explotación que tiene nuestro DataCenter y cómo tomar medidas para mejorarlas, y así conseguir que la medida global sea mejor.

Hasta aquí lo referente al consumo IT. Pero ¿y el consumo total? (Total Facility Energy) ¿Dónde se mide? Mucha gente lo está midiendo en el cuadro principal del DataCenter, es decir, además del consumo IT miden consumo de refrigeración, UPS, switches de transferencia, etc. ¡Pero esta medida es incorrecta! Si miramos la definición en inglés que hace TGG, el numerador es Total Facility Energy. Y el significado de Facility, en este caso, no es sólo la sala de ordenadores. El significado es El Centro de Proceso de Datos y todo lo necesario para que funcione. Es decir, que hay que añadir el consumo de los humanos que hacen que el tinglado funcione. Quizá la expresión no sea la adecuada, porque hay técnicos de sistemas que aunque tengan DNI no parecen humanos y probablemente no hayan nacido en este planeta, pero el consumo eléctrico que genera su trabajo hay que tenerlo en cuenta.

Así, si una organización tiene un edificio en el que se alberga el CPD y la gente del departamento de sistemas, Total Facility Energy significa Consumo del Edificio, que obviamente incluye la calefacción de los despachos de los informáticos, su iluminación, PC’s, etc. Esto tiene consecuencias:

  1. Es fácil de calcular si existe un edificio dedicado al CPD y su personal, pero en los casos mixtos (edificios que sólo son parcialmente dedicados al Centro de Proceso de Datos) hay que determinar qué parte corresponde a Total Facility Energy y es fácil cometer errores.
  2. Evidentemente, el consumo del numerador será mayor si se tiene en cuenta el verdadero significado de Total Facility Energy y, por tanto, el PUE será peor que si se calcula únicamente con la energía de la sala de ordenadores. Por eso podemos afirmar sin dudar que muchas de las cifras de PUE oídas en conversaciones de café son inventadas o simplemente están mal medidas.
  3. Un CPD mediano puede necesitar x técnicos de sistemas y un CPD grande puede necesitar el mismo número de técnicos de sistemas, así que incrementa más todavía las economías de escala entre CPD’s pequeños y grandes.

Recapitulando, hemos visto que TGG propone diversos puntos de medida, así como frecuencias diferentes para tomarlas. Eso es porque podemos hablar de tres categorías de PUE (Básico o L1, Intermedio o L2 y Avanzado o L3). Así que no vale con decir mi PUE es X. Deberíamos decir Mi PUE LY es X, donde Y es la categoría del PUE que hemos medido. A continuación tenemos el cuadro resumen:

Medida PUE Básico (L1) PUE Intermedio (L2) PUE Avanzado (L3)
Consumo IT Salida de las UPS Salida de las PDU’s Entrada equipos IT
Consumo Total Entrada del CPD1 Entrada del CPD1 Entrada del CPD1
Frecuencia de lectura Mínimo: mensual

Ideal: semanal

 Mínimo: diario

Ideal: cada hora

 Mínimo: 15 minutos

Ideal: 5 minutos

Este artículo ha salido el doble de largo de lo habitual en el blog, y aun así podría extenderse mucho más. Así que ya sabéis, quienes tengáis dudas después de leer el artículo, queráis ayuda para montar un sistema de medición en tiempo real, saber qué dispositivos son los más adecuados para montar un sistema de medición sin romper el presupuesto, etc, contactad conmigo.

 

1 Ver las consideraciones sobre lo que significa Entrada del Edificio.

Performance Indicator (II) – El PUEr

martes, 11 Jul AM | Datacenter, Eficiencia Energética, Green Grid, Métricas

[bws_linkedin display=»share»]

El primero de los tres indicadores que forman el PI es el PUEr, que no es otra cosa que el PUE ratio. Pero ¿qué es el PUE ratio?

En el post en el que introdujimos la serie de artículos sobre nuevas métricas dijimos que el PUE ha tenido la gran virtud de poner el problema de la Eficiencia Energética sobre la mesa y conseguir concienciar sobre el problema pero que, como métrica, no es muy útil. Ahora toca explicar por qué y, como siempre, habrá que recurrir a coches y camiones.

¿Qué os parece un consumo de 12 litros a los cien kilómetros? ¿alto? ¿bajo? Seguro que más de uno estáis pensando ¿doce a los cien? Dónde vaaaas! Pero la respuesta correcta es depende: si esa medida es de un utilitario es, desde luego, malísima. Pero si la medida se corresponde a un camión de 5 ejes cargado con 40 toneladas… la medida sería estratosféricamente buena, porque su consumo suele rondar los 30 litros a los cien…

Todo esto es para ilustrar algo tan básico que es de Perogrullo: al lado de una medida hay que indicar qué se está midiendo, y el problema del PUE es que no dice qué se está midiendo. Algunos listillos me diréis… sí lo dice, es el ratio entre el total de la energía consumida por el DataCenter y la energía consumida por los equipos IT. Pues entonces yo os contesto ¿qué os parece una estatura de 2,17? Porque es una medida que para humano es muy alto (ahí tenéis a Pau Gasol), pero para jirafa es enano. Así que no vale con decir estatura. Hay que decir estatura de …

Desde que el PUE se ha puesto de moda, en cualquier evento sale alguien contando que en su nuevo datacenter, o que después de modificar el datacenter han conseguido un PUE de X, donde la X tiende a ser una cifra tan cercana a 1 como irreal. Es decir, cuentan que su datacenter tiene una estatura de 2,17, pero sin decir si es humano o jirafa.

¿Qué os parece un PUE de 1,5? Pues depende de si es humano o jirafa. Si es un datacenter nuevo hecho en Noruega para albergar un superordenador al 100% de carga permanentemente y sin UPS pues es francamente malo. Pero si se trata de un datacenter legacy en Almería, en un edificio antiguo y protegido en el que las actuaciones son prácticamente imposibles y prestando servicios que requieren redundancia N+N… pues yo diría que se trata de un PUE entre bueno y muy bueno.

Es decir, que para que el PUE sea una medida útil, hay que especificar la raza del datacenter. Por eso, quienes habéis aguantado mis charlas de los últimos años, me habéis oído insistir en que hay que establecer métricas que relacionen Eficiencia Energética con desempeño IT.

Si tenemos claros estos conceptos, entonces entenderemos que la mejor comparativa posible del PUE es la que hacemos con nosotros mismos, pues es evidente que yo soy de mi raza. Lo que hay que hacer es dos cosas: la primera es medir el PUE, y al PUE medido le llamamos PUEactual, y la segunda es definir un objetivo de PUE que queremos alcanzar: PUEref. Entonces, el PUEr es el ratio entre ambos, es decir, del grado de consecución de nuestro objetivo:

PUEr = PUEref / PUEactual

Por terminar de entenderlo, supongamos que nuestro objetivo es conseguir un 1,5 de PUE. Entonces, PUEref = 1,5. Si el PUE medido es 2, PUEr = 1,5 / 2 = 0,75. Es decir, estamos al 75% de conseguir nuestro objetivo.

Para obtener el PUEactual hay que medir el PUE, y desgraciadamente no todo el mundo sabe hacerlo. En el próximo artículo hablaremos de las Categorías del PUE y cómo se miden, y también hablaremos de los rangos de PUE definidos por TGG. Como sabéis, el objetivo de estos artículos es hacer difusión de los conceptos básicos. Si queréis ampliar conocimientos o resolver dudas, contactad conmigo.

Performance Indicator (I) – Generalidades

martes, 4 Jul AM | Big Data, Datacenter, Eficiencia Energética, Green Grid, Métricas

[bws_linkedin display=»share»]

Hoy comenzamos la serie de artículos sobre nuevas métricas de DataCenter, y vamos a comenzar por la propuesta del Green Grid como métrica fundamental: el Performance Indicator (PI). Es un indicador muy potente, y para obtener todos los beneficios que nos puede dar es necesario comprender su filosofía y principios.

El PI se basa en tres indicadores. Pero lo que hay que comprender es que el verdadero indicador es la relación entre los tres que lo componen, y por eso el PI es un indicador gráfico. Es decir, no es que tengamos tres numeritos y a partir de ellos y una fórmula mágica obtengamos el número mágico. No, el verdadero indicador es un gráfico, un dibujo que cambia en función de nuestras condiciones de explotación, y simplemente viendo el dibujo obtendremos mucha información… si sabemos verlo.

En la explotación de un DataCenter influyen muchísimas variables. Si pensamos únicamente en el consumo energético son muchas las variables que incidirán, algunas continuas y otras discretas: tipo de sistema de refrigeración, temperatura de consigna, temperatura exterior, carga de procesadores, densidad eléctrica, etc. Obviamente no todas tienen el mismo grado de influencia, pero son muchas las que están correlacionadas. Hace años, en el contexto del proyecto MONICA, calculamos el modelo matemático de un DataCenter concreto, para lo cual determinamos el polinomio para estimar el consumo en función de unas pocas variables.

Vivimos en la era del Big Data, y uno de sus objetivos es analizar gran cantidad de variables con gran cantidad de datos y poder establecer sus correlaciones. Matemáticamente es sencillo, el gran problema es poder recopilar y organizar los datos para que puedan ser tratados. Bien, en la explotación de un DataCenter influyen muchísimas variables (centenares o miles), y podemos utilizar Big Data para su análisis y mejora. En nuestro grupo llevamos años haciéndolo.

Por eso debemos de entender que haya indicadores que a pesar de que midan cosas radicalmente diferentes están correlacionados, es decir, que si nos varía el indicador A nos variará también el indicador B. Seguramente A no es lo único que influye en B, pero influye. Por ejemplo, supongamos que somos los responsables de explotación de una empresa de transportes, en la que tenemos 20 camiones. Un dato que nos gustará saber es el consumo en litros por cada 100 kilómetros recorridos. Con este dato podemos tener una idea de la eficiencia de nuestra flota y si nos merecería la pena cambiar los camiones por otro modelo.

Pero para saber si estamos optimizando bien nuestras rutas, también deberíamos saber los kg de carga por kilómetro: seguro que ganamos más dinero cuanto más cargados vayan los camiones. Un camión vacío es un drama: traga gasoil, desgasta embragues y neumáticos, requiere horas de conductor y no genera ingresos.

Pero si no queremos tomar decisiones equivocadas, tendremos que tener en cuenta que ambos indicadores están relacionados: si los camiones van más descargados, consumirán menos litros de gasoil a los 100 kms que si van cargados. Es decir, en el primer indicador influirá tanto la eficiencia intrínseca del camión como el uso que hagamos de él.

En este ejemplo hemos relacionado carga y consumo, y es de sentido común pensar que mayor carga implica mayor consumo. Pero en nuestro DataCenter, si queremos tomar las decisiones correctas, tenemos que contemplar simultáneamente todos los aspectos: eficiencia, redundancia, seguridad, etc. De eso va el PI, de conseguir un indicador muy sencillo que, de un vistazo y de forma gráfica, nos permita obtener una visión global sobre el estado de estos aspectos globales y su relación. Como hemos dicho, el PI está compuesto por tres indicadores, y cada uno de ellos es muy potente y aporta mucha información de un aspecto concreto. Pero luego está el indicador global, el que relaciona a los tres.

Por eso vamos a dedicar al PI varios artículos: además de este, tendremos tres analizando cada uno de los tres indicadores que lo componen y finalmente aprenderemos a leer el indicador global. El próximo artículo se lo dedicaremos al primero de los tres indicadores del PI: el PUEr (con r pequeñita).

 

Nuevas Métricas de DataCenter

martes, 27 Jun AM | Datacenter, Eficiencia Energética, FCSCL, Métricas

Llevamos ya unos cuantos años en los que todo el mundo habla del PUE, y es obvio que mucha gente lo hace porque es una de las modas TI. Si, el mundo TI también se rige por modas, al menos en lo que al discurso se refiere, y fabricantes, integradores y usuarios adaptan sus productos a estas modas, aunque en muchos casos es una simple adaptación del lenguaje.

El PUE es una métrica y sólo una métrica. Digo esto porque mucha gente ha elevado el PUE a los altares, una especie de bálsamo de Fierabrás que se lo dábamos a nuestro CPD y le curábamos todos los males. En los últimos años, bastaba con ir al evento de turno y contar a los colegas que nuestro CPD tiene un PUE bajo parar refrendar que somos los más avanzados e innovadores del mundo mundial aunque el servicio se nos caiga tres veces por semana. He visto, por desgracia,  gente que contaba el PUE de su CPD sin haberlo medido y sin saber realmente qué es el PUE.

Pero como he dicho al inicio del párrafo anterior (hay que insistir tanto como sea necesario), el PUE es sólo una métrica, y debemos analizarla desde dos puntos de vista: el social y el técnico. Desde un punto de vista exclusivamente técnico no es una métrica muy útil (esto lo explicaré en otro artículo), pero desde el punto de vista social ha tenido una utilidad tremenda: ha servido para poner el problema de la Eficiencia Energética (así, con mayúsculas) sobre la mesa.

Pero el gran error conceptual que mucha gente ha cometido es hablar de Eficiencia Energética del DataCenter como un concepto aislado. No, no podemos hablar de Eficiencia Energética sin relacionarlo con Riesgo, Calidad de Servicio, Disponibilidad, Coste, etc. Es obvio que estos parámetros están relacionados entre sí y el quid de la cuestión es conseguir la máxima Calidad de Servicio con el menor Coste, la máxima Eficiencia, la máxima Disponibilidad, etc. Pero en esta ecuación ¿qué significan exactamente máxima y menor? Pues son términos que cada organización deberá determinar en función de su política, y que en muchos casos no son fáciles de determinar. Además, para saber si estamos cumpliendo con nuestros objetivos o no, debemos establecer las métricas adecuadas que relacionen estos aspectos y determinen nuestro grado de cumplimiento: por eso son necesarias métricas que relacionen aspectos tan dispares entre sí.

Una de las cosas que hice por la FCSCL es afiliarla al consorcio Green Grid (si no me equivoco fuimos la primera entidad española en ingresar, y actualmente sólo hay dos), y personalmente participé en algunos de los grupos de trabajo de definición de nuevas métricas. Para difundirlas, iré publicando en el blog una serie de artículos sobre las nuevas métricas, cómo son, para qué sirven y cómo se miden. Como el verano es una época ideal para leer un poquito y preparar proyectos de cara al nuevo curso, tendréis periódicamente una serie de artículos al respecto. En el próximo comenzaremos por el Performance Indicator