Seleccionar página

OSDA – Open Standard for DataCenter Availability (I)

Durante muchos años, los estándares de instituciones como el Uptime Institute, TIA y BICSI han sido ampliamente utilizados en diseño, construcción y operación de DataCenters. Son sencillos y relativamente fáciles de utilizar, y su primer objetivo es facilitarnos una clasificación básica sobre datacenters. Cada uno de ellos tiene sus peculiaridades, pero básicamente marcan los requisitos para tener cuatro categorías de centros de proceso de datos. Estas cuatro categorías tienen pequeñas diferencias entre unos estándares u otros, pero podríamos hacer una descripción somera de ellas así:

  1. Básico y no redundante: el nivel más básico no tiene elementos redundados, por lo que en caso de fallo de un componente crítico se producirá una parada. (el responsable de explotación no pega ojo)
  2. Básico redundante: los componentes críticos están redundados. (el responsable de explotación necesita una dosis fuerte de pastillas para dormir).
  3. Mantenimiento concurrente: se puede hacer mantenimiento de cualquier componente sin necesidad de parar o degradar servicios. (el responsable de explotación baja la dosis de pastillas en invierno)
  4. Tolerante a fallos: el CPD es completamente tolerante a fallos. (el responsable de explotación duerme a pierna suelta)

Los estándares marcan unos requisitos de diseño y constructivos para encuadrarse en cada una de las categorías y, si se cumplen, como consecuencia se tendrá una tasa de disponibilidad conocida de antemano. Si las políticas de explotación se adecúan a las buenas prácticas, estadísticamente deben cumplirse las tasas de disponibilidad especificadas en la norma. Durante años, estos estándares han sido muy útiles.

Pero ¿y hoy en día? ¿Son suficientes? Claramente no, y en este artículo vamos a ver por qué. Estos estándares están diseñados para un paradigma en el que cada organización tenía su centro de proceso de datos y, si la organización se lo podía permitir, uno alternativo. Es decir, estas normas asumen que una organización tiene un centro de proceso de datos propio, en el que tiene toda su producción. Como es evidente, este datacenter es crítico, y debe estar diseñado de forma robusta. Si me lo puedo permitir hago un datacenter que resista una bomba atómica, y si soy más pobretón con una o dos UPS me vale.

La informática es crítica para una organización. Si la informática se para entonces la organización se colapsa, así que tiene que funcionar sí o sí. Por eso, durante muchos años, por favor, me ponga usté un host mu caro o lo mejor que haiga y no repare en gastos. Los sistemas eran carísimos y el software tanto como el sistema o más: el coste de los mainframes y sus licencias convertían en irrisorio el coste de la electricidad, las UPS’s, las enfriadoras y demás martingalas necesarias.

Pero claro, para que funcione el host y su software, el router y todas esas puñetas hacen falta cosas básicas: electricidad y frío. Para esto las soluciones han permanecido invariables durante muchos años: en la electricidad un suministro de luz (o dos para los ricos) contratado a una compañía eléctrica. Por si falla el suministro, uno o más sistemas de alimentación ininterrumpida. Y para cuando se agoten las baterías, uno o varios generadores diesel. En el lado del frío, cacharros que generaban frío a base de compresores, se enfriaba el aire y ese aire frío se echa debajo del falso suelo. Por si las moscas, se ponen más cacharros de frío de los necesarios. Por cierto, que el viejo sistema de refrigeración por impulsión por falso suelo es un ejemplo del despilfarro energético que ha caracterizado al mundo del datacenter, porque hacerlo así es como encender el aire acondicionado del dormitorio para refrigerar el salón.

Por eso los estándares que hemos mencionado hablan explícitamente de este tipo de infraestructuras. Pero hoy en día las cosas son diferentes por muchos motivos. Uno de ellos es que tenemos un abanico de soluciones mucho mayor, y el otro es que desde hace tiempo el precio del kWh sube más que las angulas en navidad. Así que uno de los parámetros que hay que tener en cuenta en las tres fases del datacenter que hemos detallado al principio, esto es, el diseño, construcción y explotación, es el de la eficiencia, y el problema es que los estándares mencionados no contemplan para nada la Eficiencia (escrito así, con mayúsculas, como debe ser).

Para suplir esta carencia The Green Grid ha propuesto el Open Standard for DataCenter Availability (OSDA). Tal como el propio TGG indica, uno de los objetivos al proponer el OSDA es fomentar la innovación, teniendo como metas la sostenibilidad y la Eficiencia Energética. En esta serie de artículos veremos los principios básicos del OSDA y cómo utilizarlo. Y ya sabéis, si tenéis dudas o queréis averiguar el estado real de vuestro datacenter, contactad conmigo.

 

Disponibilidad y lógica difusa

En el artículo anterior dijimos que es imprescindible controlar la disponibilidad, y que es imprescindible hacerlo para poder demostrar de forma fehaciente que estamos cumpliendo el Acuerdo de Nivel de Servicio que tenemos comprometido. Esto, independientemente de que su comprobación sea muy sofisticado o no, es, en principio, binario. O es sí o es no. Mejor dicho, como la carga de la prueba recae siempre por el lado del prestador del servicio, si no es sí tenemos un problema. Es decir, que si no podemos demostrar que estemos cumpliendo, da igual que en realidad lo estemos haciendo: si no podemos demostrarlo tenemos un problema.

Supongamos que estamos midiendo nuestra disponibilidad tal como hemos dicho y que somos capaces de demostrar que estamos cumpliendo ¿Es esto todo o deberíamos ir un poco más allá? En mi opinión, esto no es bastante. Si queremos conservar nuestro cuello, es necesario que sepamos a qué distancia estamos del desastre.

Como uno es persona de ideas peregrinas, a veces cuando voy en un avión sentado al lado de la ventanilla pienso aquí se va muy cómodo (con el espacio entre asientos de hoy en día, es un decir) pero si estuviera un metro más allá... Vale, quizá el ejemplo no es muy bueno, está el fuselaje en medio. Pero la idea se entiende: a veces nos separa muy, muy poquito del desastre, y para que no suceda ese desastre lo ideal es saber a qué distancia nos encontramos de él.

Si uno se sube a la azotea de un edificio de 50 plantas siempre se corre el riesgo de caerse. Corremos riesgos al estar en alturas, al ir en coche y, prácticamente, en cualquier actividad que hagamos: la vida es riesgo. Pero sigamos con el ejemplo de la altura, porque de la misma forma que a la mayoría de las personas les dan vértigo las alturas, a la mayoría de los técnicos de sistemas les da vértigo una caída grave de servicio en la que los teléfonos echan humo.

Supongamos que mi vida es la disponibilidad, que cumplo mi SLA humano si estoy vivo. Salgo a la azotea y me quedo en el centro, lejos del borde. Hombre, en principio parece bastante seguro. Puede suceder que venga una racha huracanada de viento, arrastre mis casi cien kilos y me tire por el borde de la azotea. Puede suceder, pero es altamente improbable. Sin embargo, si voy caminando por la azotea el riesgo de caer por el borde es cada vez mayor. A menos de un metro el riesgo de tropezar y caer por la barandilla es mayor que si estoy a diez metros. Y si me subo al borde de la barandilla, mientras esté ahí estaré vivo. Pero la probabilidad de que un resbalón o una pequeña ráfaga de viendo me hagan caer es enorme, y si eso sucede, adiós a mi disponibilidad, y en este caso, para siempre.

Para prevenir esto deberíamos utilizar un sistema de lógica difusa: cuanto más cerca estoy del borde menos disponibilidad tengo. Mientras esté en la azotea, perteneceré al conjunto de los disponibles, pero si me quedo en el centro perteneceré más que si me acerco al borde, y si me caigo por el borde dejaré de pertenecer al conjunto de los disponbiles. Como veis, son los conceptos básicos de lógica difusa.

¿Cómo aplicamos todo esto a nuestro servicio IT? Bueno, pues el concepto es sencillo. Ponerlo en marcha no lo es tanto. Supongamos que tenemos un servicio. Uno y sólo uno, que no es cosa de cansarse, pero es un servicio que es crítico y nos han puesto un SLA exigente. El servicio no requiere mucha carga computacional, pero es crítico (por ejemplo, el DNS: consume poco, pero cuando no funciona arde Troya. Así que nos curamos en salud y lo ponemos todo redundado: dos servidores con dos fuentes de alimentación cada uno, dos sistemas de almacenamiento don dos controladoras cada uno, dos switches, dos sistemas de alimentación ininterrumpida, dos enfriadoras, dos técnicos de sistemas, dos cafés, etc, etc. Todo redundado por si las moscas.

Supongamos que tengo un sistema para medir el SLA que comprueba que el DNS está en marcha, responde, lo hace dentro de la latencia especificada, etc, así que queda registro de Si, está disponible. Y ahora se van produciendo averías hardware. Empezamos por una avería en una fuente de alimentación de uno de los servidores. Una pequeña minucia, pues los dos servidores siguen en marcha y, por supuesto, nuestro monitorizador del SLA ni se inmuta. Se avería otra fuente del otro servidor, se avería una enfriadora… el monitorizador del SLA sigue diciendo que todo está ok, pero la cosa cada vez pinta peor. Con los sistemas de monitorización binarios saltarán las alarmas de las averías, pero sigo sin saber lo cerca que estoy del desastre.

Al final, sólo queda uno de cada cosa: sólo queda en marcha un servidor con una única fuente de alimentación que se comunica con el mundo a través de un único switch, etc, etc. Es decir, una incidencia más y desastre seguro. Hombre, Antonio, has roto muchas cosas a la vez… si, pues rompo sólo dos: rompo los dos switches y hala, se acabó. Se paró el servicio.

Pero si utilizamos un sistema de control con lógica difusa, podemos parametrizar los valores que asignamos a estos componentes para controlar el grado de pertenencia al conjunto de los disponibles. Esto hay que hacerlo en dos formas: controlando la distancia en número de eventos que estamos del desastre y asignando probablilidades a los eventos. En el caso que hemos mencionado, la distancia mínima al desastre es dos: como hemos dicho antes, basta que fallen los dos switches. Si falla un switch no pasa nada si también falla un servidor, pero es obvio que si ha fallado un switch y un servidor es más probable el fallo total que si sólo ha fallado uno (o switch o servidor).

Esto hay que hacerlo bien, controlando todos los elementos que intervienen en cada servicio, comenzando por el cuadro eléctrico y terminando en el último componente de software. Y si con sólo un servicio y la pila de componentes que han intervenido os parece un lío, imaginad en un datacenter grande con cientos o miles de servidores y decenas de miles de servicios.

Supongamos que parametrizo mi disponibilidad difusa entre 1 y 2, en el que 2 significa disponible, riesgo mínimo y 2 significa 1, riesgo extremo. Sé que el teléfono no va a echar humo hasta que la disponibilidad baje de 1, pero seguro que mi comportamiento no va a ser igual si veo en el monitor un 1,001 que si veo un 1,999.

Análogamente, Podemos controlar los incumplimientos con lógica difusa. No es lo mismo que dos de cada diez peticiones se respondan con un tiempo de latencia un poquitín superior al especificado a que el servicio no responda. Incluso cuando nos van a dar collejas es necesario tener las herramientas pera intentar minimizar el número y fuerza de las mismas.

Si os fijáis, esto es una ampliación de los conceptos utilizados en en Thermal Resilience a todos los componentes y servicios del datacenter. Como lo estamos midiendo en positivo, estamos hablando de disponiblidad, pero no deja de ser una forma de medir en tiempo real el riesgo asociado a los servicios: el inverso de la disponibilidad es el riesgo tal como lo trata la ISO 27001.

Cualquier servicio es crítico una vez transgredido el acuerdo de nivel de servicio, así que a cualquier CTO le encantaría saber si las collejas están lejos o cerca, y esto, en el fondo, es un mero problema de probabilidades. Eso sí, un CTO tiene que ser consciente de que  los sucesos improbables también ocurren. Tienes dos ases en la mano, y en la mesa ves un as, dos cuatros, un nueve y un tres. Te ves feliz con tu trío pensando que te has ganado un dinero fácil cuando resulta que el que tenía cara de pardillo tenía otros dos cuatros en la mano, enseña su póker y te deja con cara de memo.

Si, la Ley de Murphy es inexorable. Por eso, cuánto más lo tengamos todo bajo control, mejor. Por eso la disponibilidad es mayor cuando se está sentado confortablemente en el salón que cuando se está como el de la imagen. Así que no lo dudéis, implantad un sistema de gestión de disponibilidad/riesgo así. Si no sabéis como, consultadme!

 

Performance Indicator (VII): Cómo establecer objetivos

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 (VI): La verdadera potencia del indicador.

En la serie de artículos precedente hemos ido viendo las generalidades sobre el Performance Indicator y los indicadores que lo componen. En este vamos a ver la verdadera potencia del PI, que es el conjunto. Si, el PI en su conjunto es un indicador por sí mismo, y  además es muy, muy potente.

Como hemos visto en los artículos anteriores, el PI tiene tres componentes: el PUEr, que es el ratio entre el PUE actual y el objetivo de PUE (mide la distancia a la que nos encontramos de nuestro objetivo); el Thermal Conformance, que mide el grado de cumplimiento de la especificación térmica; y por último el Thermal Resilience, que mide la capacidad del datacenter para hacer frente a problemas en el sistema de refrigeración. Es obvio que cada uno de ellos tiene una función concreta y proporciona información muy valiosa, pero ¿y el conjunto?

Supongamos que quiero hacer un uso eficiente de mi coche. ¿Qué significa uso eficiente? pues no lo tengo muy claro, y voy a establecer indicadores para ello. Hombre, un indicador básico para ello se ha utilizado toda la vida: cuántos litros de combustible gasta por cada 100 kilómetros recorridos. Hala, ya tenemos un indicador: litrosaloscien, y vamos a llamarle Consumo. Es evidente que cuanto más bajo es el indicador, mejor: si consumo siete litros a los cien estoy peor que si consumo cinco litros a los cien. Bueno, ya tengo un indicador, y además está relacionado con la Eficiencia Energética, voy por buen camino. Ahora ¿voy sólo en el coche? En algunas ciudades como Madrid existen calles y zonas restringidas a vehículos con dos o más ocupantes. No hay que ser un lince para ver intuitivamente que cuantas más personas ocupen un vehículo se consigue una mejor optimización de recursos, así que parece que otro buen indicador puede ser ese: cuántas personas ocupan el coche por cada 100 kilómetros. Si un coche recorre cien kilómetros, 50 de ellos con una persona y los otros 50 con dos, no hacen falta muchas matemáticas para saber que el valor del indicador sería 1,5. Llamemos a este indicador Ratio de Ocupación.

Bien, hemos establecido dos indicadores para nuestro automóvil: Consumo y Ratio de Ocupación. En el primero, hemos visto que cuánto más bajo y próximo a cero sea el valor, mejor. Y en el segundo, si pensamos que el coche está homologado para cinco plazas, es que cuanto mayor y más próximo a cinco sea el valor, mejor. Obviamente, si quiero mejorar, debo estar atento a los dos indicadores para que el primero tenga valores cada vez más próximos a cero y el segundo valores más próximos a cinco.

Pero ¿y si los indicadores no son independientes, es decir, están relacionados? En este caso ¡es obvio que lo están! Si se suben más personas al coche pesará más y, por tanto, consumirá más. Es decir: mejorar el segundo indicador implica empeorar el primero. Por eso tenemos que estar atento a ambos. Imaginemos que si Ratio de Ocupación es 1 entonces el consumo Consumo es 5, pero que si radio de ocupación es 5 consumo sube a 7,5 ¿cuál de las dos situaciones es mejor?

En nuestro datacenter queremos conseguir la mayor fiabilidad, calidad de servicio, eficiencia, etc. Para esto, a veces establecemos indicadores, nos fijamos en ellos y nos obsesionamos con mejorarlos, y no nos damos cuenta de que quizá, al mejorar un indicador concreto, estamos empeorando otro igual de importante. Por eso, debemos establecer indicadores de parámetros críticos que están relacionados, y debemos ser nosotros mismos los que establezcamos sus objetivos sin perder de vista la visión global.

A cualquier responsable de datacenter le aterra la posibilidad de tener problemas en la climatización, y la forma fácil de solventar esto es  redundando ¡venga máquinas! parafraseando a Groucho Marx en el Oeste: ¡Más máquinas! ¡Es la guerra! Sin embargo, si pongo tres docenas de climatizadoras en una sala de veinte racks (quizá sea un pelín exagerado hacer algo así) dormiré muy tranquilo pensando que tengo redundancia suficiente de climatización. Pero si hago eso y a la vez miro el PUEr debería tener pesadillas. Análogamente, otro responsable que tenía su datacenter y estaba tan feliz con él resulta que llega el Antonio Ruíz Falcó y le convence para medir el Thermal Conformance, se da cuenta de que está lejos de cumplir, cambia consignas en la climatización… y baja el Thermal Resilience.

Es decir, que como es evidente, los tres indicadores están íntimamente relacionados entre sí, y actuar sobre uno de ellos afecta a los otros dos. Si, PUEr, Thermal Conformance y Thermal Resilience están íntimamente emparentados, y si tocamos uno afectaremos a los otros dos, y es algo que nunca debemos de perder de vista. Precisamente, esta es la forma del Performance Indicator: visual. Es n triángulo, y sobre él podremos ver nuestro estado actual, pero también podremos predecir cómo será cuando lleguemos a nuestro objetivo. Si, porque nos permite hacer eso, establecer un objetivo. Sólo nosotros podemos decidir de todos los aspectos que influyen en nuestro datacenter cuáles son más importantes, estratégicos, etc. Pero, sobre todo, la importancia de no fijarse en un único aspecto. Conozco datacenters que, durante muchos años, su objetivo era la disponibilidad, y todo lo enfocaban a ella. Por eso hacían auténticas aberraciones en eficiencia. Pero no sólo eso, como ni siquiera se establecían métricas adecuadas no se conseguía mejorar la disponibilidad.

Así que, el Performance Indicator es un indicador gráfico Es un triángulo equilátero, en cuyo vértice superior está el Thermal Resilience, en el vértice inferior derecho el PUEr y en el vértice inferior izquierdo el Thermal Conformance. En los vértices se encuentra el hipotético 100% de cada uno de los parámetros, y en el centro del triángulo el otro extremo de la escala, que lo podemos establecer nosotros. Lo normal es que sea sobre el 80% para verlo con buena resolución, pero dependiendo de cuál sea nuestro punto de partida quizá tengamos que ser más conservadores y poner otros valores. En los ejes de los tres indicadores pondremos nuestro valor para cada uno de ellos, y veremos que se forma un triángulo isósceles.

La imagen siguiente muestra el aspecto del Performance Indicator tal como lo define The Green Grid:

 

Como vemos en la imagen, con la carga actual el PUEr está a algo más del 85% de su objetivo, hay un 100% de Thermal Resilience y el Thermal Conformance está próximo al 100%, en cualquier caso por encima del 95%. También vemos que si se mejora el PUEr hasta alcanzar algo más del 90%, pero entonces el Thermal Conformance y el Thermal Resilience bajan aproximadamente al 95%. ¿Es esto bueno o malo en sí mismo? Pues depende de los objetivos de la organización que explota el datacenter, del riesgo admisible, de la calidad de servicio objetivo, etc. Pero, lo que es muy importante, es tener muy claro que debemos mantener una visión global, y para eso el Performance Indicator es una gran ayuda. Podremos encontrarnos multitud de situaciones, pero las básicas son tres: datacenters muy optimizados en el que los tres parámetros estén cerca de los vértices, datacenters desastre en el que los tres parámetros estén cerca del centro y datacenters desequilibrados en el que haya un parámetro cerca del vértice y los otros cerca del centro, etc.. En el segundo y tercer caso hay, obviamente, mucho trabajo por delante porque hay problemas en el horizonte.

En el próximo artículo haremos una guía para orientarnos de cómo establecer objetivos para el Performance Indicator. Mientras tanto, ya sabéis: si tenéis alguna duda o queréis implementar el PI en vuestra instalación, consultadme (por cierto que pronto anunciaré novedades en este último punto).

 

 

Performance Indicator (V): Thermal Resilience

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

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!