Seleccionar página

Performance Indicator (I) – Generalidades

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

 

Consolida, que algo queda 3.0

Decíamos la semana pasada que la clave este año es hacer más con menos. Y una buena forma de hacerlo es consolidar. Más de uno dirá «yo ya consolidé hace cinco años cuando acometí el proceso de virtualización. Reduje a la quinta parte el número de servidores físicos. Mi granja de virtualización ha seguido creciendo, y a día de hoy tengo tropecientas máquinas virtuales».

En los últimos meses he hablado con algunos CTO’s que transmiten mensajes como el anterior, y que piensan (ingenuos ellos) que ya tienen los deberes hechos. Tampoco son  capaces de darse cuenta de que cambiar sus cincuenta servidores distribuidos en siete armarios («es que el comercial me regaló el rack con aquellos tres servidores) que compramos para el proyecto X») por un chasis blade que en unas pocas U tiene 16 servidores y un buen montón de núcleos le ha creado un montón de problemas, pues no hay manera de refrigerarlo. Hay algunos casos exagerados de este tipo: son los que yo llamo CPD Faro. CPD’s de doscientos metros cuadrados que antes estaban llenos de racks y se han quedado vacíos, que ahora tienen un único rack en el centro con uno o dos chasis llenos de blades y muchicientas máquinas virtuales. Como es lógico, aunque la refrigeración de la sala está a tope (impulsuión por falso suelo, of course), el rack está al rojo. Quizá no se aprecie a simple vista, pero el rack está al rojo. Y el que no lo quiera creer, que le haga una foto con una cámara termográfica. Por eso estos son los CPD’s Faro.

Pero esta versión de Consolida que algo queda era la 1.0. Ahora estamos en Consolida que algo queda 3.0 (muchos no van a pasar por la 2.0). Consiste en hacer algo parecido pues también se trata de reducir el número de elementos físicos  aumentando la carga de los restantes. Pero en este caso los elementos físicos no son simples servidores: ahora hay que hacerlo con CPD’s completos. Ya hemos mentado la bicha: cerrar CPD’s. Quien tiene diez puede vivir con tres, y quien tiene uno puede vivir sin ninguno.

Hoy he estado en una reunión de proyecto en la que el cliente lo tiene muy claro. Va a reducir costes, pero no calidad de servicio. Quien tenga dudas sobre cómo se hace ésto, que pregunte. Para eso estamos.

El «secador de cuerpo entero»

Rack 128 Servidores "45Kw"

Rack 128 Servidores

A raíz del post sobre la alta densidad, muchos me habéis preguntado cómo son los racks con más de 40Kw. Algunos con bastante escepticismo, pero la realidad es que habéis mostrado curiosidad por cómo es el secador de cuerpo entero.

Pues es muy sencillo: en cada rack hay cuatro chasis HP C7000. En cada chasis, hay 32 servidores HP BL2x220C: este servidor tiene precisamente este nombre (2x) porque en cada hoja hay dos servidores. Es decir, en las 16 bahías del chasis entran 16 hojas con 2 servidores cada una: 32 servidores. Cada servidor tiene dos procesadores Intel Xeon E5450 con cuatro cores: ocho cores por servidor, 256 cores por chasis. Y como cada rack tiene 4 chasis, en un único rack hay 128 servidores y 1024 cores. Si seguimos desglosando, cada servidor tiene un ratio de 2GB/core o lo que es lo mismo 16GB/servidor. Por tanto en cada rack hay 2TB RAM.

Repetición: 128 servidores, 1024 cores y 2TB por rack. A día de hoy, con procesadores con más cores, la cosa sería más bestia…

Pero eso no es todo. Ahora hay que ponerlos a trabajar. En las instalaciones de propósito general, además de haber muchos menos servidores que en una dedicada a HPC, las tasas de utilización por servidor son muy bajas. En servidores dedicados a cálculo, los procesadores están al 100% permanentemente… y precisamente, los procesadores (y también las memorias, que es el otro componente que trabaja intensivamente en cálculo) son los componentes que más consumen.

La mayoría de la gente no es consciente de esto. A continuación tenéis una gráfica del consumo de un chasis:

Chasis C7000 encendido y sin carga

Chasis C7000, 32 servidores encendidos y sin carga

Como podéis ver, el consumo del chasis en números redondos es de 4Kw. En esto están incluidos los 32 servidores (encendidos, sistema operativo -RHE Linux- cargado pero sin ejecutar programas de cálculo), seis fuentes de alimentación, seis ventiladores, OA de control del chasis, cuatro switches gigabit y cuatro switches infiniband.

Como son cuatro chasis por rack, 4×4=16Kw. Es decir, si encendemos los 128 servidores de un rack, consumen 16Kw… antes de hacer nada útil. 16Kw en un rack es una cifra absolutamente estratosférica para una instalación convencional. Pero ahora vamos a ver qué pasa cuando los servidores se ponen a trabajar:

Chasis C7000 con los 32 servidores ejecutando un Linpack

Consumo Chasis C7000 con los 32 servidores ejecutando un Linpack

 

Como podéis ver, el consumo sube de 10Kw. En función del programa concreto y su configuración, puede llegar hasta un poco más de 11Kw por chasis. Como el rack tiene cuatro chasis… ahí están los 45Kw por rack.

En este ejemplo concreto, en el que el consumo está ligeramente por encima de los 10Kw en el chasis, está ejecutando un test de Linpack N=275.000, np=256. Es decir, calculando un sistema de ecuaciones lineales de 275.000 ecuaciones con 275.000 incógnitas, utilizando los 256 cores del chasis. En otras ejecuciones que supongan todavía más saturación de memoria y más estrés es cuando se llegan a superar los 45Kw.

Como bien os podéis imaginar, los racks con esta configuración no están «simplemente encendidos», así que la instalación trabaja a unos regímenes muy elevados…

El siguiente paso es refrigerar los servidores. Y no sólo refrigerarlos, sino hacerlo de una forma eficiente. Pero esto os lo contaré en otro momento.

Os dejo una foto de la «salida del secador», que espero que os guste. Y una advertencia: cuando vayáis a comprar un blade, averiguad si el fabricante sabe cuánto consume. Por absurdo que parezca, es bastante posible que las especificaciones estén mal en un 100%.

 

La Alta Densidad como necesidad para la Eficiencia Energética

Cada vez que cuento que en la instalación de la FCSCL hemos superado densidades de 44Kw por rack, veo dos tipos de reacciones: quienes lo ven en una presentación suelen ser escépticos (total, todos sabemos que en este oficio hay cierta costumbre de inflar números…). Pero también están las visitas a quienes se lo cuento in situ, mientras sufren lo que es estar detrás de racks chufando más de 40Kw por el tubo de escape: lo más parecido a un secador de cuerpo entero que os podáis imaginar.

En el discurso sobre nuestro secador siempre resalto dos cosas. La primera, que tener una instalación de estas características es todo un reto de ingeniería. Y la segunda, y mucho más importante,  es que esta alta densidad es fundamental para alcanzar una alta eficiencia energética. Es de sentido común: tratar un punto caliente es complicado, pero si se consigue es más eficiente que si se tiene calor disperso.

Empezamos con este discurso hace muchos años, y predicando en el desierto. Recuerdo, en unas jornadas de usuarios de supercomputación del año 2006, que hice una presentación sobre el gran problema de la eficiencia energética. La audiencia no me hizo puñetero caso: casi todos tenían unos clústeres de cálculo estupendos, pero a ninguno le tocaba pagar la luz. Además, y como ya he contado en más de una ocasión he conocido directores de sistemas que utilizaban el cuánto gasta mi camión como unidad de medida del gran director de sistemas que soy.

Pero moda o no moda, el mensaje va calando. Sobre todo, si el mensaje viene de fuera: tenemos tanta fe en nosotros mismos que damos más credibilidad a los mensajes del exterior. ¿Cuándo nos daremos cuenta de que esta actitud tiene mucho que ver con la crisis que padecemos?. Así que, para que no me tengáis que hacer caso a mí y podáis hacer caso a mensajes de fuera, os dejo un enlace a un artículo interesantísimo publicado por The Green Grid: Breaking new Ground on Datacenter Efficiency. Es un caso de éxito de como eBay ha conseguido una altísima eficiencia gracias a la alta densidad.