Seleccionar página

Disponibilidad y lógica difusa

[bws_linkedin display=”share”]

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 (I)

[bws_linkedin display=”share”]

En muchas ocasiones, al acercarnos a alguna materia, damos por sentados los conceptos básicos. No nos atrevemos a preguntar, los intuimos y resulta que la base de todo no la tenemos clara. Es evidente que no se puede levantar un pilar resistente sin una zapata sólida. Esto pasa con cualquier área de conocimiento, y las TIC no son ajenas a este fenómeno. Es más, por lo que he podido comprobar en mis muchos años dedicados a esto, es algo que se da con mucha frecuencia. Sobre todo cuando se introducen conceptos o tecnologías novedosas: se ponen de moda y para no quedar como pardillos actuamos como si los conociéramos de toda la vida aunque no tengamos claro de qué van. Un ejemplo de esto es el consabido PUE, que como ya hemos explicado en artículos anteriores, hemos oído a mucha gente hablar de PUE sin un conocimiento preciso de qué es.

Pero algunos habéis vencido estas reticencias, y me habéis pedido que amplíe el último artículo y aclare los conceptos básicos sobre disponibilidad. Así que en ello estamos, en explicar con un poco más de rigor esos conceptos básicos.

Así que vamos a hablar de disponibilidad en dos ejes: el de ¿disponibilidad de qué? y el de ¿disponibilidad de qué tipo?.  Así que en este artículo vamos a hablar del ¿Disponibilidad, de qué?, y para ello vamos a intentar definir disponibilidad. Recordad que en el artículo anterior vimos que ante la pregunta de qué es, mucha gente contesta ¡qué pregunta más tonta! Disponibilidad es… disponibilidad!. Bueno, pues según el diccionario de la Real Academia de la Lengua, en su primera acepción, disponibilidad es cualidad o condición de disponible. Aplicado a las TIC, vamos a dar una definición formal de disponibilidad:

Disponibilidad es el porcentaje del tiempo en el que un recurso está disponible.

Pero como lo que hace un datacenter y un servicio TIC, es precisamente eso, prestar un servicio, hay que hablar de disponibilidad en tres momentos diferentes:

  1. El primero de ellos es del de la determinación del acuerdo de nivel de servicio (SLA) del datacenter o del servicio IT en cuestión. Quienes prestan servicios para terceros o tienen una ISO 20000 en vigor esto lo deberían tener claro, pero hay datacenters medianos que prestan servicio a una única organización que no tienen un SLA bien definido con su propietario. Da igual que sea un ayuntamiento, una universidad, una mediana empresa o quien seas: si eres un datacenter o si prestas servicios IT, aunque sólo sea a tu organización, tienes que tener obligatoriamente un SLA. Este SLA es la disponibilidad del servicio que prestas: así que esta es la primera fase en la que hay que hablar de disponibilidad: la del compromiso de calidad de servicio. Por ejemplo, te voy a prestar el servicio X y va a estar disponible el 99% del tiempo. Es decir, es el requisito de disponibilidad.
  2. La siguiente fase es obvia: si me he comprometido a una determinada disponibilidad tendré que diseñar mis infraestructuras y sistemas para poder cumplir eso. Para no dar palos de ciego en este reto, existen ayudas para ello. Por ejemplo, la norma TIA-942 establece cuatro niveles de requisitos técnicos, y lo que dice es “si cumples el nivel de requisitos X tu disponibilidad será del Y%”. Obviamente esto es una distribución estadística. La probabilidad de que tú tengas un póker y tu rival tenga una escalera real es muy baja, pero puede suceder. Si se cumplen los estándares del nivel 4 de la TIA-942 se supone que se conseguirá una disponibilidad del 99.995%, pero la realidad puede ser diferente. En cualquier caso, la norma TIA-942 y similares son un buen punto de partida para diseñar unas infraestructuras capaces de cumplir con el requisito de disponibilidad. Es decir, esta etapa es la del diseño, la de la especificación de disponibilidad.
  3. Por último, toca demostrar que gracias que la especificación ha sido la correcta, estamos cumpliendo con el requisito. Es decir, toca comprobar en tiempo real la disponibilidad y guardar los resultados históricos para poder utilizarlos cada vez que haga falta. Esto debe hacerse de forma que no permita controversia. Es más, puede suceder que mi cuello dependa de ello (o pleitos millonarios, y si se pierden mi cuello también peligra). Es la tercera fase: la de medir la disponibilidad.

En resumen, ya sabemos que tenemos que hablar de disponibilidad en tres momentos: en de establecer los requisitos del servicio, el de especificar las infraestructuras y el de medir el resultado de explotación.

Pero ¿es esto suficiente? ¡No! Quedan dos cosas: definir con precisión qué es un recurso y definir con precisión qué significa disponible. Esto lo haremos en los próximos artículos, en el que además de de hablar de esto os introduciré algún concepto innovador que llevo tiempo utilizando. Mientras tanto, ya sabéis: si tenéis dudas o queréis implementar algún sistema de control, contactad conmigo.

 

 

¿Qué es la disponibilidad?

[bws_linkedin display=”share”]

¿Que qué es disponibilidad? ¡Qué pregunta más tonta, disponibilidad es…. disponibilidad! A muchos os parecerá absurdo este diálogo, pero os puedo asegurar que lo he tenido más de una vez: cuando le preguntas a alguien qué significa disponibilidad, es probable que conteste así.

El año pasado, en un seminario que di sobre eficiencia, conté que Usain Bolt hizo un tiempo de 9,81 en los 100 metros lisos en las olimpiadas de Río de Janeiro, y que Scott Reardon hizo un tiempo de 12,26 segundos en las mismas olimpiadas. Hice una pregunta muy facilita: ¿Quién lo hizo mejor? A pesar de ser muy obvio que había trampa, todo el mundo contestó al unísono que Usaín Bolt (que es realmente una pena que se haya retirado porque este tipo es marciano). Acto seguido desvelé la trampa: puse la foto de Scott Reardon que acompaña a este post y en la que podéis comprobar que le falta una pierna.

Efectivamente, Scott Reardon es un atleta australiano que compitió en Río 2016 en los 100 metros lisos. No sólo eso: ganó la medalla de oro. Si, con un tiempo de 12,26 ganó la medalla de oro en los 100 metros lisos en los juegos paralímpicos. Por tanto, corría en los 100 metros lisos, pero en una categoría diferente a Usain Bolt ¿Y por qué en una categoría diferente? Pues para que sea más fácil comparar peras con peras y manzanas con manzanas. Es más, si mis datos no me fallan en los juegos paralímpicos se puede competir en los 100 metros lisos en 16 categorías diferentes. Cada una de ellas tiene unas reglas muy claras sobre quién puede participar y cómo es la competición.

Este ejemplo sirve para ilustrar muy bien que, cuando se da una cifra, por sí misma no sirve de nada. Ya vimos algo parecido con el PUE: para poder valorarlo en su justa medida no basta con saber la cifra: también es necesario saber dónde se ubica el datacenter, a qué se dedica, etc: ya dijimos que no es lo mismo un datacenter para HPC en Noruega que uno para proceso transaccional de muy alta disponibilidad en el Sáhara. Con la disponibilidad sucede lo mismo: aunque todos tenemos claro lo que es, debemos definir excatamente a qué nos estamos refiriendo, y para esto tenemos que tener muy claras dos cosas:

  • La primera de ellas es si estamos hablando de disponibilidad especificada o medida. Por ejemplo, el estándar TIA-942 dice que si un DataCenter cumple con los criterios del nivel tres de la norma (Tier III) el datacenter tendrá una disponibilidad del 99,982% del tiempo. Es decir, la distribución estadística dice que si cumples con el nivel tres de la norma lo normal es que tengas esa disponibilidad, pero puede no ser así.
  • La segunda es el alcance de lo que llamamos disponibilidad ¿a qué nos referimos con disponibilidad del datacenter? ¿a la disponibilidad de las infraestructuras? ¿a la disponibilidad de las aplicaciones? Son aspectos que hay que precisar siempre. Si soy un proveedor de colocation me basta demostrar que las infraestructuras eléctricas y de refrigeración funcionan correctamente. Sin embargo, si soy un proveedor IaaS, me interesa demostrar que la plataforma está siempre disponible, y eso incluye no sólo a las infraestructuras del CPD, también a la granja de servidores y su almacenamiento, así como la capa de networking. Obviamente, al usuario le afecta toda la pila, desde la aplicación que está arriba de la pirámide al cuadro eléctrico de la entrada, pasando por servidores, almacenamiento, networking, enfriadoras, etc.

Yo siempre soy partidario de medir, porque la infraestructura mejor diseñada del mundo no sirve de nada si los procedimientos de explotación no son buenos. Así que, al igual que hemos hecho con el PUE, vamos a ver cómo medimos la disponibilidad: qué se mide, cómo se mide, etc. Eso lo veremos en la próxima serie de artículos. Mientras tanto, como siempre, si tenéis alguna duda poneos en contacto conmigo.

 

Distribución de la Carga

[bws_linkedin display=”share”]

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 (VII): Cómo establecer objetivos

[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!