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!

 

Conceptos básicos de disponibilidad (II)

En el artículo anterior vimos que podemos abordar la disponibilidad en tres momentos distintos. Ahora hay que hablar del de qué. Es decir, tenemos que definir muy claramente a qué recurso nos referimos cuando decimos la disponiblidad es 99,998%. Ya lo hemos dicho anteriormente, dependerá de quién seamos y qué hagamos: un DataCenter que preste servicios de housing querrá demostrar que es capaz de mantener los racks en condiciones operativas un determinado porcentaje de tiempo.  Esto es muy importante en función de cuál sea el alcance de la responsabilidad de cada uno: el rack puede estar perfecto, pero si la aplicación está colgada hay un problema. Hay que tener en cuenta que en el mundo cloud moderno, la pila IT puede tener diversos responsables: uno para las infraestructuras de datacenter, otro para la plataforma hardware y networking, otro para el software, etc. Para cada uno de ellos, el concepto disponibilidad tendrá un alcance diferente en función de cuál sea el recurso en cuestión.

Por esta razón es muy importante que cuando hablemos de disponibilidad delimitemos bien su alcance, es decir, el de qué. Pero, también hay que definir con precisión disponible, o lo que es lo mismo, cómo vamos a medir la disponibilidad. Como la mayoría de los técnicos de sistemas saben, una de las herramientas más utilizadas para monitorizar disponibilidades ha sido Nagios. Es software libre y fácil de utilizar, aunque sus ficheros de configuración son farragosos. Nagios ha tenido la gran virtud de extender la monitorización, y muchos sitios se han empezado a monitorizar gracias a Nagios (o lo que es lo mismo, sin Nagios no se hubieran monitorizado, lo que es terrible). Pero Nagios está muy orientado a monitorizar utilizando “pings”, con un algoritmo muy sencillo: si responde, está vivo. Este es el método que muchos utilizan para comprobar la disponibilidad, pero no tienen en cuenta que vivo no es lo  mismo que disponible. Muchas veces los dispositivos responden al ping, pero no están disponibles. Le hago ping al servidor web y el servidor responde, pero eso no significa que el servidor esté bien.

Por eso hay que definir con precisión qué significa estar disponible, y esto es la letra pequeña del SLA. Si seguimos con el ejemplo del servidor web, podríamos decir algo como: se comprueba mediante un comando HTTP GET que el servidor responde, que devuelve la página principal comprobando con el patrón que no ha sido modificada por un hacker y que la respuesta se produce en menos de x milisegundos. Aquí podemos ser tan barrocos como queramos, comprobando todo el árbol web o no, controlando desde el tiempo de respuesta a la introducción de datos en formularios, etc.

Bien, pues esto hay que hacerlo independientemente del alcance. Traslademos el ejemplo del web a un prestador de servicios de housing. En este caso, el SLA hará mención de las infraestructuras: Cada rack dispondrá de alimentación de 220V con una capacidad de 32A (o 16, o 64, o 96 o lo que corresponda), con una temperatura inferior o igual a…, etc., etc.

En resumidas cuentas, cuando medimos disponibilidades tenemos que leer la letra pequeña del SLA a que nos hayamos comprometido y adoptar las medidas técnicas para poder demostrar fehacientemente con medidas que estamos cumpliendo nuestra parte.  En este punto, hay quienes optan por SLA’s poco claros en los que no se explicita con precisión el alcance del servicio que se presta. Bien, esto es un gran error estratégico: si lo hacemos así en cuanto haya discrepancias no podremos demostrar que estamos cumpliendo y, como el cliente o el usuario siempre tienen la razón, tendremos problemas.

En resumen, el problema de la disponibilidad lo debemos abordar en tres momentos:

  1. Al establecer el Acuerdo de Nivel de Servicio (SLA) que prestaremos a nuestros clientes y/o usuarios: ya dijimos que siempre debemos tener explicitado el SLA aunque trabajemos para nuestra propia organización.
  2. Al diseñar las infraestructuras y sistemas que utilizaremos para prestar los servicios.
  3. Una vez que están los servicios en producción deberemos realizar medidas reales para poder corroborar con datos que estamos cumpliendo nuestra parte del trato.

Transversalmente a estas etapas debemos dejar clara la definición de recurso y la definición de disponible, pues juntas forman el alcance de los servicios que vamos a prestar.

¿Es esto todo? ¡No, se escapa un pequeño detalle! Este detalle es el concepto novedoso del que os hablaba en el artículo anterior y que explicaré con profundidad en el próximo artículo.

 

 

 

Distribución de la Carga

Hoy toca hablar de carga en el DataCenter, y para hablar de carga qué mejor que hablar de aviones, barcos y camiones, que ya sabéis que aparecen con una cierta regularidad en el blog.

El parámetro fundamental de los vehículos de transporte, sean terrestres, marítimos o aéreos es la carga máxima. Como es evidente, el transportista querrá que sus vehículos vayan cargados al máximo, pues esta es la forma de optimizarlos. Cuando un avión, barco o camión está parado está metiendo billetes en la destructora de papel: parados no generan ingresos pero generan muchos gastos. Sin embargo, hay una situación peor que tenerlos quietos, que es tenerlos en movimiento con poca carga. Los costes son mucho mayores que estando parados y los ingresos serán bajos.

De todas formas, hay que entender un concepto importante. Cuando un sistema está diseñado para soportar una carga X, es evidente que su rendimiento máximo medido en términos de gasto por unidad de carga se alcanzará a carga máxima. Un DataCenter, es bajo este punto de vista, igual a aviones y barcos: su rendimiento óptimo lo alcanzará a carga máxima. Sin embargo, la gran diferencia entre un DataCenter y los vehículos de transporte es que, mientras que lo normal es que los vehículos de transporte de mercancías trabajen siempre a plena carga, en los datacenters no: casi siempre hay capacidad excedente. Se construye el datacenter pensando en la carga de hoy en día y en la que vendrá en los próximos X años. Es decir, un datacenter normal no sólo tiene capacidad para albergar más servidores, sino que los servidores que tiene en producción también tienen muchos ciclos de CPU excedentes. Salvo en sistemas HPC, donde en teoría deben encontrarse todas las CPU’s al 100%, en datacenters de propósito general es muy normal encontrarse tasas de utilización de CPU < 10% en sistemas poco virtualizados y < 50% en sistemas virtualizados.

Todo esto, obviamente, penaliza el rendimiento del DataCenter. Es la razón, como vimos en el artículo anterior, de que aunque la ingeniería que proyectó el DataCenter hizo unas predicciones de PUE, una vez en marcha las mediciones reales sean peores. Pero en esto no podemos hacer nada: la carga es la que es actualmente y la única opción es gestionarla de la mejor forma posible. Así que veamos cómo lo hacen en aviones, barcos y camiones.

En el mundo del transporte hay muchos roles. Uno es el del financiero que quiere hacer las cosas al menor coste posible. Otro es el del piloto, camionero o capitán del barco que, además de su sueldo, se juega su cuello. Lo sé por experiencia propia: si te pones a los mandos de un avión quieres aterrizar entero, porque si el avión aterriza “en piezas”, su contenido también,  y en este sentido el piloto también es “contenido”. Si un vehículo de transporte está a media carga, al financiero le preocupará el coste, pero al piloto (o al camionero o al capitán del barco) le preocupará (y mucho) la distribución de la carga.

No hace falta ser un genio de la física para darse cuenta de que si un barco cargado al 50% se le pone toda la carga en un lado, escorará. En los aviones, es crítico distribuir los pesos: volar en un avión desequilibrado es peligrosísimo (o directamente imposible). Y, además del peligro, la distribución de la carga nos afectará al consumo. Así que, cuando no estamos al 100%, tenemos un problema de gestión y distribución de la carga.

Un DataCenter es como un barco o un avión: estos últimos transportan cargas, y los datacenters soportan cargas computacionales, con la peculiaridad mencionada de que en raras ocasiones tenemos el datacenter al 100%. Así que en el datacenter tenemos siempre el problema de distribución de la carga. Si, es cierto: debemos gestionar cómo distribuimos la carga en el datacenter. He conocido muchos datacenters en el que los sistemas se instalan de cualquier manera, es decir, en el primer sitio que haya disponible y preferentemente a la altura de los ojos. Distribuir la carga del datacenter afecta a dos cuestiones importantísimas: la primera, la eficiencia. La segunda, más importante todavía: fiabilidad y seguridad. Si, no gestionar la carga, además de hacernos menos eficientes, puede provocar problemas de fiabilidad y seguridad.

¿Cómo controlar esto? En primer lugar, el Performance Indicator (y en especial mantener un ojo en el Thermal Conformance y otro en el Thermal Resilience) es una muy buena herramienta. Como continuación, deberíamos disponer de una herramienta que nos permita relacionar el Performance Indicator y sus tres indicadores con riesgos tal como los define la ISO 27001.

Si queréis ayuda sobre cómo distribuir la carga en el datacenter, o cómo realizar un análisis de la carga existente y sus implicaciones sobre los riesgos, consultad conmigo.

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).