martes, 27 Jun AM | Datacenter, Eficiencia Energética, FCSCL, Métricas
Llevamos ya unos cuantos años en los que todo el mundo habla del PUE, y es obvio que mucha gente lo hace porque es una de las modas TI. Si, el mundo TI también se rige por modas, al menos en lo que al discurso se refiere, y fabricantes, integradores y usuarios adaptan sus productos a estas modas, aunque en muchos casos es una simple adaptación del lenguaje.
El PUE es una métrica y sólo una métrica. Digo esto porque mucha gente ha elevado el PUE a los altares, una especie de bálsamo de Fierabrás que se lo dábamos a nuestro CPD y le curábamos todos los males. En los últimos años, bastaba con ir al evento de turno y contar a los colegas que nuestro CPD tiene un PUE bajo parar refrendar que somos los más avanzados e innovadores del mundo mundial aunque el servicio se nos caiga tres veces por semana. He visto, por desgracia, gente que contaba el PUE de su CPD sin haberlo medido y sin saber realmente qué es el PUE.
Pero como he dicho al inicio del párrafo anterior (hay que insistir tanto como sea necesario), el PUE es sólo una métrica, y debemos analizarla desde dos puntos de vista: el social y el técnico. Desde un punto de vista exclusivamente técnico no es una métrica muy útil (esto lo explicaré en otro artículo), pero desde el punto de vista social ha tenido una utilidad tremenda: ha servido para poner el problema de la Eficiencia Energética (así, con mayúsculas) sobre la mesa.
Pero el gran error conceptual que mucha gente ha cometido es hablar de Eficiencia Energética del DataCenter como un concepto aislado. No, no podemos hablar de Eficiencia Energética sin relacionarlo con Riesgo, Calidad de Servicio, Disponibilidad, Coste, etc. Es obvio que estos parámetros están relacionados entre sí y el quid de la cuestión es conseguir la máxima Calidad de Servicio con el menor Coste, la máxima Eficiencia, la máxima Disponibilidad, etc. Pero en esta ecuación ¿qué significan exactamente máxima y menor? Pues son términos que cada organización deberá determinar en función de su política, y que en muchos casos no son fáciles de determinar. Además, para saber si estamos cumpliendo con nuestros objetivos o no, debemos establecer las métricas adecuadas que relacionen estos aspectos y determinen nuestro grado de cumplimiento: por eso son necesarias métricas que relacionen aspectos tan dispares entre sí.
Una de las cosas que hice por la FCSCL es afiliarla al consorcio Green Grid (si no me equivoco fuimos la primera entidad española en ingresar, y actualmente sólo hay dos), y personalmente participé en algunos de los grupos de trabajo de definición de nuevas métricas. Para difundirlas, iré publicando en el blog una serie de artículos sobre las nuevas métricas, cómo son, para qué sirven y cómo se miden. Como el verano es una época ideal para leer un poquito y preparar proyectos de cara al nuevo curso, tendréis periódicamente una serie de artículos al respecto. En el próximo comenzaremos por el Performance Indicator
martes, 20 Jun AM | Cambio, Datacenter, Eficiencia Energética, FCSCL, HPC
Ha llegado el momento de cambiar: vine a León para seis meses y llevo ya nueve años, primero como director técnico y en los últimos dos años y medio como director general. Lejos en el tiempo quedan aquellos días de la primavera de 2008 en la que recibí una llamada (gracias, Luis!) pidiendo ayuda para un proyecto apasionante: crear un centro de supercomputación desde cero.
Y eso hicimos. Comenzamos por apostar por una idea: construir un centro de supercomputación cuyo eje fuera la Eficiencia Energética. En aquella época pocos hablábamos de la importancia de la EE, pero está claro que el tiempo ha acabado dándonos la razón. Diseñamos y construimos un DataCenter que, a día de hoy, sigue siendo una referencia en EE. Es más, sigue siendo el DataCenter más denso de España, porque no conozco ningún otro que alcance los 50kW/rack.
Son muchos y muy importantes los logros conseguidos en la FCSCL, y eso a pesar de una situación económica muy adversa. Es más, el gran logro de los últimos dos años ha sido precisamente ese: darle la vuelta a la situación económica, y pasar de un déficit endémico a un superávit muy significativo que permite encarar el futuro con optimismo.
Otro de los grandes hitos ha sido la integración de la FCSCL en la Red Española de Supercomputación (RES), así como conseguir su inclusión en el Mapa de Grandes Infraestructuras Científico Técnicas (ICTS) del Estado. Este es un club realmente exclusivo: en Castilla y León hay dos ICTS, pero ninguna de ellas es de titularidad exclusiva de la Junta, así que la FCSCL será la primera.
Un logro importantísimo del que me siento especialmente orgulloso es de la Red Regional de Ciencia y Tecnología de Castilla y León, un proyecto de una enorme complejidad y que ha supuesto años de trabajo, desde la búsqueda de la financiación al diseño técnico y ejecución. Castilla y León era la única comunidad autónoma pluriprovincial que no tenía red propia de ciencia y tecnología. Gracias a nuestro proyecto ahora la tiene, y no me duelen prendas en decir que tiene la Red autonómica más avanzada de España.
En resumen, han sido nueve apasionantes pero agotadores años, así que es el momento de cambiar. Creo que dejo a mi sucesor, a quien deseo suerte y éxito en el reto que asume, una muy buena herencia. Por mi parte, un montón de proyectos en cartera. Y como ahora podré disponer de algo más de tiempo, el blog cobrará nueva vida.
domingo, 25 Mar PM | Datacenter, Eficiencia Energética
La próxima semana tiene lugar el ASLAN (días 27, 28 y 29) y el congreso de enerTIC (días 28 y 29 de Marzo). Así que es un momento ideal para hablar de PUE, por lo que haré la presentación «Monitorización y Control Inteligente del PUE» en el Foro Tecnológico (será el día 28 de Marzo a las 11:45).
En la presentación os contaré qué es el PUE y el DCIE, cuales son sus componentes y cómo se comportan. Pero más importante aún, os introduciré al concepto EIT (Eficiencia IT) y desmitificaremos algunas cuestiones alrededor del PUE. Para hablar del PUE es necesario conocerlo, monitorizarlo y controlarlo. Para eso os presentaré MONICA.
El proyecto MONICA es un desarrollo liderado por Catón en el que participan la FCSCL (Fundación Centro de Supercomputación de Castilla y León) y el grupo HPCA (High Performance Computing Architectures) de la UJI (Universidad Jaume I).
El proyecto tiene dos objetivos principales:
- Monitorizar el PUE. Es decir, monitorizar en tiempo real todos los dispositivos necesarios en el CPD para poder tener datos del PUE con precisión.
- Controlar de forma inteligente y automática el CPD para mejorar la eficiencia. Por ejemplo: encendiendo o apagando servidores, desplazando máquinas virtuales de servidor, cambiando consignas en equipos de climatización, etc.
Es más, este aspecto puede realizarse conforme a unas reglas de negocio predefinidas, y puede usarse para diferentes propósitos. Mejorar la eficiencia energética es uno de ellos, pero puede ser también la minimización del riesgo.
El proyecto nos ha permitido aprender mucho sobre PUE y eficiencia en una gran instalación real. Por ejemplo, el hecho de que el PUE, tal y como está definido por The Green Grid, es una integración de un año. Y la optimización del PUE requiere trabajar con la derivada… Os presentaré algunos resultados y conclusiones sobre PUE y eficiencia que probablemente sorprendan a más de uno.
… Y hasta aquí puedo leer. Os recomiendo (a los que podáis) que vengáis el miércoles a la charla. No obstante, después de la charla colgaré aquí las transparencias, y me tenéis a vuestra disposición para consultas y dudas.
viernes, 9 Mar PM | Eficiencia Energética, HPC
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, 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:
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%.
domingo, 26 Feb AM | HPC
Esta semana hemos tenido la reunión de arranque de un interesante proyecto de investigación: Amiga4Gas. En la reunión estábamos los equipos de los tres miembros del proyecto: IAA (CSIC), BSC y FCSCL. Es decir, un centro de investigación en astrofísica y dos centros de supercomputación.
Nuestro rol como centro de supercomputación es doble: además de desarrollar los componentes de software necesarios, tenemos que poner nuestro músculo computacional a disposición del proyecto para realizar los cálculos necesarios.
Las imágenes a procesar proceden de radiointerferómetros. Y en estos momentos está en proyecto el que será el mayor radiointerferómetro del mundo: SKA (siglas de Square Kilometer Array). No voy a aburriros ahora con lo que significa SKA desde el punto de vista de la ingeniería, tenéis la información básica en el artículo de la wikipedia. Lo relevante desde el punto de vista TI es el flujo de datos que dará SKA cuanto esté completamente operativo en 2024. Ni más ni menos que 1TB de datos por segundo.
Es decir, este pequeño instrumento nos dará un exabyte de datos por día. Tenemos doce años para diseñar cómo serán los sistemas capaces de procesar, transmitir y almacenar semejantes flujos de información. Si me permitís un chiste malo, esto ya no es un problema de Big Data, sino más bien de Huge Data. Y necesita tecnología que todavía no tenemos.
Mientras tanto, nosotros diseñaremos los sistemas para tratar los cubos actuales de datos (comienzan en 100MB) de forma completamente automática, utilizando para ello una federación de infraestructuras heterogéneas.
