Seleccionar página

Performance Indicator (VII): Cómo establecer objetivos

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

[bws_linkedin display=»share»]

El otro día un responsable de un importante datacenter me decía: vale, vale, Antonio, me has convencido: voy a medir el Performance Indicator pero, ¿Qué objetivos pongo? ¿Por dónde empiezo?.

No existe una respuesta universal a esta pregunta, obviamente. Como hemos visto en la serie de artículos, depende de muchos factores: uso del datacenter (no es lo mismo HPC que servicios web, por ejemplo), calidad de servicio que se necesita, riesgos asumibles, etc,etc.

Así que establecer de antemano cuál debe ser el objetivo del Performance Indicator es hacer un brindis al sol. Vale, es obvio que quiero un 100% de PUEr, un 100% de Thermal Conformance y un 100% de Thermal Resilience. Y ya que estamos de cienes, que me toquen otros cien millones en el Euromillones. Puestos a pedir ¿por qué no?

Si, por pedir que no quede, pero si en el Euromillones me toca algo más que el reintegro me suelo dar por contento. Así que empecemos a ser un poco realistas. Fijemos objetivos realistas, y si lo hacemos es cuando verdaderamente podremos obtener beneficios. El primer objetivo es una perogrullada, pero es quizá el más importante: MEDIR.

Yo tengo que adelgazar, este verano me he pasado con la cerveza y la barbacoa (la carne es débil, veo comida y…). Pero ¿cuánto tengo que adelgazar? Antes que nada necesito saber de dónde parto: tendré que pesarme antes de empezar. Luego, en función de mi constitución, mi estatura y mi estilo de vida podré establecer cuánto debo pesar, podré analizar la diferencia y establecer el plan para llegar al objetivo (normalmente es ejercicio y hambre).

Bueno, pues en el datacenter tengo que hacer lo mismo. Lo primero MEDIR. El PUEr depende del PUE, así que tengo que medir éste. Medir bien el PUE (ver los artículos anteriores) tiene su intríngulis, así que hay que hacerlo bien. Una vez que mida el PUE me llevaré la sorpresa de que el PUE instantáneo varía bastante a lo largo del tiempo dependiendo de las condiciones de explotación.

El siguiente paso no tiene dificultad técnica, pero tiene la enjundia de que puede ser necesario instalar muchos sensores en el CPD, y es medir el Thermal Conformance. Eso sí, hay que tener en cuenta que el Thermal Conformance no es el mero mapa de temperaturas, hay que dividir por la parte proporcional de la carga. Así que deberemos saber qué porcentaje de carga en kW hay que asignar a cada sensor de temperatura, y lo suyo es hacer esto con una aplicación que lo haga automáticamente. Si medimos bien el Thermal Conformance es bastante probable que nos llevemos algún susto morrocotudo: a pesar de que en el CPD hace frío, resulta que a algunos sistemas les está entrando el aire mucho más caliente que nuestra consigna. Resulta, además, que es a los servidores críticos a los que les pasa (por aquello de la ley de Murphy). Bueno, pues en este caso el Thermal Conformance te ha proporcionado dos noticias: una buena y una mala. La mala es que tienes sistemas calientes, y la buena es que lo sabes y puedes tomar medidas.

Si al medir el Thermal Conformance te has llevado un susto, es probable que al medir el Thermal Resilience te dé un jamacuco. Recuerda que la carga no es plana, y recuerda que hay que contemplar el peor problema posible del sistema de refrigeración.

Cuando ya tenemos en marcha las tres cosas es bastante normal encontrarnos cosas de este tipo:

  • ¡Uy, al medir el PUE nos ha salido una cifra por encima de 2! ¿no decía el proyecto del CPD que íbamos a tener un PUE de 1,4? Esta frase es muy común. No, el ingeniero que hizo el proyecto no te engañó, calculó que el PUE iba a ser 1,4 en unas condiciones concretas, que normalmente incluyen carga máxima. Es como el consumo de la ficha de los coches: todos sabemos que el consumo que aparece en el folleto no lo conseguimos nunca. No significa que el folleto nos engañe. Simplemente, como hay que normalizar  cómo se mide, se hizo la norma NEDC, que lo que viene a decir en román paladino es en condiciones ideales el consumo de tu coche es x, pero tú ya sabes que las condiciones normales de uso no son las ideales.
  • Tenemos una temperatura de consigna de 24º, el CPD está fresquito y nos ha salido un Thermal Conformance del 70%. Esto es también bastante común. Depende de cómo sea el sistema de refrigeración, obviamente. Pero no es raro que, aunque la temperatura de consigna sea baja, encontrarse que al medir el Thermal Conformance salgan cifras del 70%. En este caso… Houston, tenemos un problema. Hay que analizar por qué y corregir la situación. Además, como hemos dicho antes, tenemos que ver qué hace ese 30% de carga que está fuera de especificaciones. Si es carga crítica, es imperativo hacer algo. Esto forma parte del Performance Indicator y la gestión de riesgos.
  • Resulta que yo creía que estaba sobrado de refrigeración, gasto una barbaridad en máquinas, mantenimiento y electricidad y me sale un Thermal Resilience alarmantemente bajo. Esto también es mucho más común de lo que pensamos. De hecho suele suceder en muchas ocasiones.

Este artículo iba de cómo establecer los objetivos del PI, así que vamos allá:

  1. El primer objetivo y más importante es medir el Performance Indicator. Al hacerlo, aflorarán muchos de los problemas que tenemos en nuestro datacenter y de los que todavía no somos conscientes, y podremos ponerles remedio.
  2. Para el PUEr, un buen compromiso es, precisamente, el mencionado antes. Si la ingeniería que nos ha proyectado el DataCenter ha calculado el PUE, ese debe ser el objetivo de PUE. En el ejemplo que hemos puesto antes, si el objetivo de PUE es 1,4 y el PUE actual es 2, entonces el PUEr es el 70%.
  3. En el Thermal Conformance deberíamos estar por encima del 90%, pero en cualquier caso lo importante es saber qué sistemas son los que tenemos trabajando fuera de especificación y su grado de criticidad. La SAN puede representar un porcentaje minúsculo de la carga del DataCenter, pero si es justo eso lo que tenemos trabajando fuera de rango, igual tenemos que cortarnos las venas pronto (siempre es preferible dejárselas largas)…
  4. El objetivo ideal de Thermal Resilience es, obviamente, del 100%. Pero tenemos que tener claro cuál es el propósito del datacenter, el riesgo asumible, calidad de servicio comprometida, etc. Lo óptimo es que el TC sea igual o superior a la carga crítica.

Esto son líneas muy generales, pero lo que finalmente se establezca dependerá de muchos factores. Acercar el TC y el TR al 100% cuestan mucho dinero, y debemos analizar si merece la pena o no. ¿Hay carga que pueda ser apagada en caso de problemas del sistema de refrigeración? ¿Los sistemas que cuya temperatura está fuera de especificación son críticos? ¿cuál es la calidad de servicio comprometida?

Lo ideal sería que el PI formara parte de un sistema ISO 27001- ISO 20000, en el que controlemos tanto la seguridad como la calidad del servicio. Aunque no lo parezca, el PI es un pilar importantísimo para las dos ISO’s mencionadas: ¿cuáles son los riesgos asociados  a tener un TC y un TR bajos? ¿cómo puede afectar a la calidad del servicio? Así que os recomiendo consultar con expertos estos aspectos para no tener sustos en el futuro: quien haya sufrido un paso por cero sabe de lo que hablo. Así que si tenéis dudas, queréis poner en marcha un Performance Indicator o queréis ayuda para establecer los objetivos, ponedme un correo o llamadme, pero medid, medid, malditos!

 

 

 

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.

 

 

 

 

 

Y ahora, Big Data

domingo, 17 Jun PM | Big Data, Datacenter

El próximo martes 19 de Junio se celebra, organizado por iiR España, el evento «Big Data 2012». En el blog hemos hablado mucho de Eficiencia Energética y Cloud Computing, las dos grandes modas TIC. Y Big Data es la tendencia emergente. El concepto es muy sencillo: el volumen de información está literalmente explotando, y tenemos que desarrollar tecnologías para adaptarnos a esta demanda.

La gente de iiR, atentos siempre a las tendencias del sector, han organizado el evento y una vez más han tenido la amabilidad de invitarme a dar una charla: «Big Data & Data Center: Infraestructuras para almacenamiento y proceso de Big Data». En ella veremos algunas cifras sobre la magnitud de la explosión de datos, y haremos un análisis sobre cómo serán las infraestructuras para almacenamiento y proceso. Y, sobre todo, las razones de por qué van a ser así.

Tenéis más información del evento en su web. Espero veros allí, y que la charla sea de vuestro interés. Por cierto, que ha habido un cambio de horario en el programa, la charla será a las 17:15.

Bienvenido seas, enerTIC

jueves, 9 Feb PM | Eficiencia Energética

Foto Fundadores enerTIC

Foto Fundadores enerTIC

A lo largo de los últimos meses se ha constituido la plataforma enerTIC. Es una plataforma constituida por 25 socios fundadores, y a la que se han incorporado ya algunos socios más. El objetivo de la plataforma, tal como se define en su web (www.enertic.es), es «Contribuir al desarrollo del potencial de transformación de las Tecnologías de la Información y Comunicaciones en el ámbito de la eficiencia energética en España con el apoyo de las Empresas Asociadas e instituciones públicas, en favor de una economía más competitiva y sostenible”.

Lo decíamos en la presentación, la eficiencia energética es otra de las modas imperantes en el sector TIC. Y bendita moda. Desgraciadamente, hasta hace muy poco no había conciencia en el sector sobre el gran problema energético. En mi caso, fui consciente del problema en cuanto creé la empresa. a finales de los noventa construimos el primer cluster medianamente grande. Si mal no recuerdo, eran 70 nodos de los de entonces. yo había instalado muchísimos sistemas en el centro de investigación donde trabajaba… pero nunca había visto una factura de electricidad. Y en mi empresa no sólo tenía que ver las facturas, sino que tenía que pagarlas de mi bolsillo.

Los clusteres de cálculo son muy intensivos en consumo de energía. Además, la diferencia de consumo entre un servidor con una tasa de utilización baja a otro con la CPU al 100% es prácticamente el triple (algún día os mostraré datos sobre esto). Un ejemplo: Caléndula, el cluster de la FCSCL, tiene armarios con 128 servidores (es decir, 1024 cores por rack). Estos armarios consumen, cuando están a plena carga, ¡más de 40Kw!

Por ello quienes nos dedicamos a HPC debemos ser pioneros una vez más. Manejamos las instalaciones que más consumen: cientos o miles de servidores trabajando al 100%. Sin embargo, y hasta hace muy poco, muchos utilizaban el consumo al revés: mira lo grande que es mi camión, porque gasta una barbaridad.