Seleccionar página

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

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

 

 

 

 

 

Entrevista en TicParaTodos.es

Héctor Hernández me ha hecho una entrevista para su blog www.ticparatodos.es. Bueno, en realidad hacía tiempo que me lo había propuesto, pero con la agenda de los últimos tiempos se ha demorado el poder hacerla. Gracias, Héctor, por tu interés y tu paciencia!

Lo que me planteó fue todo un reto: contar qué es la supercomputación y para qué se utiliza, pero de una forma que pudiera entenderlo todo el mundo. Así que más que hablar de ordenadores… hablé de hoyos, picos… Finalmente pudimos hacer la entrevista y está colgada en el blog de Héctor. La entrevista la podéis ver aquí, espero que os guste. Enhorabuena por tu blog, Héctor!

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

 

Lo que se nos viene encima…

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.