Seleccionar página

Distribución de la Carga

martes, 26 Sep PM | Cloud Computing, Datacenter, Eficiencia Energética, HPC, Métricas, Uncategorized

[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 (V): Thermal Resilience

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

[bws_linkedin display=»share»]

Una vez transcurrido el parón veraniego, volvemos a la carga con la serie de artículos sobre el Performance Indicator. En esta ocasión, hablaremos del tercer indicador: el Thermal Resilience.

Los responsables de sistemas y/o directores de TI saben que, en la mayoría de sus casos, su cuello depende de que los sistemas funcionen: no me cuentes historias, haz que funcione y haz que funcione ya! Por eso muchos tienen una palabra en la cabeza: redundancia. Es evidente que cualquier dispositivo puede fallar, así que hay que tenerlo redundado por si las moscas. Durante la época de las vacas gordas, y más en los ochenta y noventa, en los que la informática era la estrella de la organización, esto no era un problema. Hay directores de sistemas que, como el coche tiene cuatro ruedas, llevan cuatro ruedas de repuesto porque todo debe estar redundado. Ya dedicaremos alguna entrada del blog a redundancia y sus conceptos básicos, pues tiene mucha más enjundia de la que parece y hay bastante gente que no lo tiene claro.

La definición intuitiva del Thermal Resilience es la capacidad para hacer frente a problemas en el sistema de refrigeración, y mucha gente interpreta que esta capacidad es igual a redundancia. Pero (volvemos al concepto de redundancia) el error es pensar que lo único que tenemos que tener en cuenta en nuestra redundancia son los posibles fallos en el sistema de climatización. No, esto no es así. Nuestra resistencia a fallos varía en el tiempo en función de las condiciones de explotación, y esto es lo que mide el Thermal Resilience.

Para simplificar las cosas y entenderlo fácilmente vamos a poner un ejemplo sencillito. Supongamos que tenemos un CPD clásico, con refrigeración por falso suelo, en el que tenemos tres CRAC’s repartidos por la sala. Si cada uno de ellos tiene una capacidad de refrigeración de 50kW, tendremos una capacidad total de 150kW. Si la carga en un momento dado es de 45kW, se tendrá una redundancia N+2: podrán fallar dos CRAC’s y, en teoría, no habrá problemas (en teoría, porque en la práctica depende de cada sala concreta, ver el apartado de Thermal Conformance). Resulta que, en el momento en el que un CRAC había fallado y otro estaba fuera de servicio por revisión, los del departamento financiero (siempre tienen el don de la oportunidad) habían lanzado un proceso de business inteligence con unos cubos OLAP enormes, los sistemas se pusieron a tope y la carga había subido a 75kW. Así que en ese momento puntual tenemos 50kW de capacidad frigorífica para hacer frente a una carga de 75kW, por lo que tendremos problemas sí o sí.

Este ejemplo era muy sencillo. En realidad, el sistema de refrigeración es un mecano complejo y más en la actualidad, en el que es fácil encontrarse simultáneamente CPD’s que disponen de más de un sistema de refrigeración y que cada uno de ellos tenga n componentes. Por ejemplo, por un lado puede haber free cooling directo  y por otro un sistema basado en agua en el que haya enfriadoras de agua en el exterior e intercambiadores de calor en la sala. La capacidad de refrigeración del freecooling directo dependerá de la temperatura exterior, y la del sistema de agua dependerá de si funcionan todas las enfriadoras y todos los intercambiadores.

Por otra parte, lo hemos dicho una y mil veces, la carga es dinámica. Lo es por dos factores, y el primero de ellos es elemental: a lo largo del tiempo instalamos servidores y equipos y los damos de baja. Tenemos nuestro flamante CPD recién construido y estrenamos el sistema de refrigeración, que estará diseñado para tener una determinada redundancia a una determinada carga nominal. Si sólo instalamos un servidor tenemos una redundancia enorme y a medida que vamos instalando servidores la carga aumenta y la capacidad para hacer frente a problemas baja. El segundo factor es menos tenido en cuenta y es que la carga de los sistemas es dinámica, varía (y puede hacerlo mucho) en función de las condiciones de explotación. Los que nos dedicamos a la supercomputación lo sabemos muy bien, el consumo de los servidores prácticamente se triplica cuando ponemos los procesadores a tope. Un clúster HPC de 250 nodos consumirá unos 40kW encendido y con el sistema operativo cargado, pero su consumo se triplicará en cuanto le soltemos un sistema de ecuaciones medianamente puñetero: nuestro consumo habrá subido a 120kW y, si ese clúster está instalado en la hipotética sala que hemos mencionado antes ¡habremos pasado de tener redundancia N+2 en el sistema de refrigeración a no tener redundancia por el simple hecho de lanzar un programa a nuestros servidores!

Esto es, precisamente, lo que mide el Thermal Resilience. En la entrada anterior definimos el Thermal Conformance como el porcentaje de carga al que le está entrando el aire a temperatura correcta. Bueno, pues la definición que hace TGG del Thermal Resilience es el porcentaje de carga al que le entra aire a temperatura admisible en el peor caso de fallo del sistema de refrigeración. Esto requiere definir dos cosas: qué es temperatura admisible y qué es peor caso del sistema de refrigeración:

IT Thermal Resilience = Eq Load (Tinlet < 32º under worst case cooling failure) / Total Eq. Load

Como se ve en la fórmula, el propio TGG propone 32º como temperatura admisible. Pero lo difícil es definir  qué es el peor caso de fallo del sistema de refrigeración. En el ejemplo de antes, en el que había un sistema de refrigeración sencillo con tres CRAC’s, es que fallen dos. De los tres indicadores que forman el PI es el más difícil de calcular, pues hoy en día las configuraciones son complejas, y el concepto peor fallo del sistema de refrigeración puede ser difícil de precisar. Así que, como siempre, si tenéis dudas consultad.

En el próximo artículo hablaremos de la verdadera potencia del PI: cómo los tres indicadores tiran unos de otros, es decir, cómo están relacionados para consigamos en nuestro datacenter el mejor equilibrio entre eficiencia, redundancia y fiabilidad.

 

 

 

 

 

Performance Indicator (II) – El PUEr

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

[bws_linkedin display=»share»]

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

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

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

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

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

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

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

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

PUEr = PUEref / PUEactual

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

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

Performance Indicator (I) – Generalidades

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

[bws_linkedin display=»share»]

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

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

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

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

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

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

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

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

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

 

Data Center, Infrastructure & Operations Management Summit (II)

lunes, 23 Ene PM | Big Data, Cloud, Cloud Computing, Datacenter, Uncategorized

Aunque ya han pasado algunas semanas del evento, tenía pendiente la segunda entrada dedicada al Data Center Infrastructure & Operations Management Summit. Así que, como lo prometido es deuda, aquí está.

En la keynote de la que os hablaba en la entrada anterior, en la que oí la frase que me gustó tanto (don’t be a custodian of legacy technologies) los ponentes introdujeron un concepto que me gustó mucho: Bimodal IT. Esta idea luego estuvo presente en todas las ponencias del evento de una u otra manera.

Los directores de sistemas son –somos- como camioneros: utilizamos máquinas grandes, pesadas y sofisticadas para prestar un servicio. Y, como buenos camioneros, nos gusta nuestro camión, lo cuidamos, lo mantenemos, lo mejoramos… y, por supuesto, cuando nos juntamos con otros camioneros hablamos de camiones. Como es lógico, presumimos de que el nuestro tiene más potencia, más marchas, más ejes… Nos gusta tanto nuestro camión que a veces se nos olvida que lo importante no es si la reductora hace esto o lo otro o si los diferenciales son de un tipo u otro. Lo realmente importante es transportar mercancías, y hacerlo con seguridad, puntualidad, calidad del servicio, con el mínimo coste y el mínimo impacto en el medio ambiente. Por esta razón, y sólo por esta razón, es por la que tenemos el camión.

El día a día nos tiene tan absorbidos que a veces nos cuesta darnos cuenta de cosas tan básicas. Por ejemplo, ¿en qué debemos pensar para mejorar la sanidad? Quien tenga mentalidad de camionero pensará en comprar sistemas más modernos, más potentes, nuevo instrumental, nuevos sistemas de diagnóstico, etc. Pero para mejorar la sanidad, en lo que hay que pensar es en el paciente. En sus expectativas, en sus problemas de salud y en cómo mejorar su calidad de vida.

En conclusión, tenemos que trabajar el plano concreto y el plano conceptual a la vez, sin descuidar ninguno de los dos: eso es el Bimodal IT. El primer modo es el concreto, el cercano al camión y al business as usual, es predecible y su objetivo es la estabilidad. El segundo modo es exploratorio y disruptivo, y su objetivo es la flexibilidad y la velocidad.

 

Un bonito ejemplo de legacy: el IBM 360 M91 que el Goddard Space Center de la NASA compró en 1967 para el programa Apollo. 10M$, 2Mb de RAM.