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

 

 

 

Performance Indicator (IV) – IT Thermal Conformance

[bws_linkedin display=»share»]

Hoy toca hablar del segundo indicador del PI: el Thermal Conformance, es decir, cumplimiento térmico. Pero ¿qué quiere decir cumplimiento térmico?

Los que visitáis con frecuencia CPD’s habéis comprobado que en ellos hace frío. En alguna conferencia hemos contado que una de las razones para que esto sea así es histórica: los viejos mainframes de los setenta y ochenta consumían poco y por tanto el coste de refrigeración era una fracción ínfima respecto al coste de explotación del bicho, así que era necesario crearles una aureola esotérica, y para eso el frío ayuda mucho: el mainframe se encontraba en un altar de condiciones muy especiales, empezando por el frío. Así que, tradicionalmente, en los CPD’s ha hecho excesivo frío. Los sistemas deben estar en el rango de temperatura especificado por el fabricante: no más, pero tampoco es necesario que esté a menos, ya que en este caso ni va a funcionar mejor ni más rápido.

Gracias a que algunos hemos dado mucho la tabarra con este tema, mucha gente se ha dado cuenta de que la temperatura del CPD tiene una influencia decisiva en la Eficiencia Energética. Hace unos años esto importaba un pimiento a la mayoría de la gente: al director de TI lo único que le interesaba es que los sistemas funcionaran, y le daba igual si gastaba mucha electricidad o poca. Normalmente ni se enteraba del coste de la electricidad, pues son otros departamentos los que se ocupan de ellas (¡grave error, querido Watson!).

Sin embargo, ahora esto ya no es así: entre que aprieta la piedra al zapato de la pasta, aprieta la piedra al zapato de la ecología y aprieta la piedra al zapato de la Eficiencia, ya no hay quien de dos pasos sin ver si puede hacer algo para mejorar la Eficiencia y, por tanto, las facturas a pagar por la organización, el medio ambiente, la emisión de CO2, la imagen del departamento… Es más, recuerdo una anécdota personal. En las jornadas del Proyecto de e-Ciencia en Andalucía celebradas en 2007 hablé sobre Eficiencia Energética y TIC… y la audiencia se me dormía. Como me precio de ser un conferenciante capaz de captar la atención de la audiencia, me sorprendió. Así que en la celebración de esas mismas jornadas dos años después hice la misma charla con una pequeña modificación: donde ponía kWh cambié a Kg de CO2. Es decir, averigüé cuánto CO2 había que emitir a la atmósfera para generar un kWh según el mix energético de aquel año. A partir de ahí, hice la misma presentación, pero hablando de toneladas de CO2 emitidas a la atmósfera en vez de kWh que es un concepto aburrido. Como todos llevamos un ecologista dentro, la charla fue un éxito.

No hay que ser un genio para darse cuenta que el coste de refrigeración tiene un impacto enorme en la explotación de un CPD. En el pasado sólo preocupaban las consecuencias de un posible problema en la refrigeración. Pero hoy, además de eso, nos preocupa su coste. En un CPD legacy, puede pegarse un recorte significativo a los gastos de refrigeración a base de buenas prácticas, sin realizar apenas inversiones: distribuir correctamente las cargas, separar zonas frías y calientes y, la más importante de todas, tener una temperatura correcta. Es por eso que muchos responsables de explotación han añadido una palabra a su vocabulario: setpoint. Vamos, algo tan tonto como la temperatura de consigna del sistema de refrigeración, que en el pasado la programó el instalador y nunca se cambió. Ahora hemos aprendido que la podemos cambiar, es más, que la debemos subir y que para eso los fabricantes de los servidores hacen recomendaciones. No sólo los fabricantes, instituciones como ASHRAE hacen recomendaciones sobre cuál debe ser la temperatura de consigna en un CPD.

Pero hay que tener en cuenta un factor muy importante (y aquí vamos al meollo del Thermal Conformance): una cosa es la temperatura de consigna del sistema de refrigeración y otra diferente es la temperatura a la que el aire entra al servidor correspondiente. Es fácil ilustrar este concepto viendo la siguiente foto:

Muchos, en casa o en la oficina, tendréis algo así. Y habréis sufrido las discusiones: el que está sentado en el sofá debajo del split de aire acondicionado se quejará de que tiene exceso de aire frío en el cogote, pero el que está sentado al otro lado de la habitación se quejará de que pasa calor ¿A cuántos os pasa esto mismo en la oficina?. Es decir, yo he programado una temperatura de 24º al aparato, pero esto no quiere decir que consiga que toda la habitación esté uniformemente a 24º.

Bueno, pues en nuestro CPD pasa esto mismo. Pasará en mayor o menor medida en función del tipo de sistema de refrigeración, distribución de las salidas de aire, etc., pero pasará. Así que supongamos que vamos haciendo caso de recomendaciones y ponemos un setpoint de 26º, es decir, lo que queremos es que el aire entre a 26º a nuestros servidores.

Entonces, si lo que queremos es que entre aire a 26º a nuestros servidores ¿lo estamos cumpliendo? O, mejor dicho, ¿en qué medida lo estamos cumpliendo? Esto es, exactamente, el Thermal Conformance: el grado de cumplimiento de la especificación térmica. Vamos a explicarlo fácil: supongamos que tenemos cuatro racks, y que en tres la temperatura del aire de entrada está por debajo del umbral especificado y uno en el que está por encima. Es cierto que en el 75% por ciento de los racks entra el aire a temperatura correcta, pero ¿qué carga representa? Imaginad que en los tres racks en los que la temperatura entra correcta hay pocos servidores y tienen una carga de 1000W cada uno, y en que entra la temperatura incorrecta tenemos un blade con una carga de 7000W. La realidad es que en este hipotético CPD con 10.000W de carga ¡el aire entra a temperatura incorrecta al 70% de la misma! Eso es, exactamente, el Thermal Conformance: el indicador que nos dice a qué porcentaje de carga le está entrando aire a temperatura correcta.

Por cierto, que el ejemplo puesto no es tan descabellado: conozco CPD’s que tenían un montón de servidores legacy, y que en algún momento de la historia han hecho un proyecto de consolidación (¡Bien!) y han sustituido 100 servidores por un flamante blade sobre el que se han virtualizado los servidores. Ese blade, cuando se compró, hubo que instalarlo en el rack que estaba libre, que estaba en un extremo de la sala y al que llega ya poco flujo de aire… Desde el punto de vista funcional, genial. Desde el punto de vista de la eficiencia, también, seguro que han disminuido consumo. Pero han creado un punto caliente que acabará generando problemas de fiabilidad al sistema de refrigeración y al propio blade. Porque, una de las consecuencias del Thermal Conformance, es que hay una correlación entre tasa de averías y temperatura de entrada de aire si esta es excesivamente alta. Por cierto, en este punto una colleja colectiva: cuando se instala un servidor en un rack vacío la tendencia es, por comodidad, instalarlo a la altura de los hombros… pero si el sistema de refrigeración es por impulsión de aire en el falso suelo, poco aire frío llega a la parte superior de los racks.

Como la recomendación de ASHRAE es impulsar entre 18-27º, la estandarización del cálculo del Thermal Conformance que nos hace TGG es:

IT Thermal Conformance = Eq Load (Tinlet < 27º) / Total Eq. Load

Donde Eq Load es la carga en kW de los equipos IT. Es decir, para calcular el Thermal Conformance tenmos que dividir el porcentaje de carga IT a la que le llega la temperatura por debajo de 27º  por el total de carga IT. Como es evidente, necesitamos medir las temperaturas a las que entra el aire en los equipos. La especificación de TGG dice que hay que poner tres sensores por rack: arriba, en medio y abajo.

Intentad hacer un mapa mental de vuestro CPD y pensad ¿cuál sería mi IT Thermal Conformance? Os aseguro que si tenéis un CPD con refrigeración por falso suelo os llevaréis sorpresas desagradables. Imaginad que implantáis un sistema de medida del Thermal Conformance y que el primer número que os sale es malo. Intuitivamente es fácil comprender que si intentáis mejorar el TC a base de fuerza bruta inmediatamente subirá el PUE ¿comprendéis ya por dónde van los tiros del “indicador triple”, es decir, el Performance Indicator? Lo seguiremos viendo en los próximos artículos. Y ya sabéis, si queréis montar un sistema de medida del Thermal Conformance o tenéis alguna duda… consultad conmigo!

 

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