Seleccionar página

¿Qué es la disponibilidad?

[bws_linkedin display=»share»]

¿Que qué es disponibilidad? ¡Qué pregunta más tonta, disponibilidad es…. disponibilidad! A muchos os parecerá absurdo este diálogo, pero os puedo asegurar que lo he tenido más de una vez: cuando le preguntas a alguien qué significa disponibilidad, es probable que conteste así.

El año pasado, en un seminario que di sobre eficiencia, conté que Usain Bolt hizo un tiempo de 9,81 en los 100 metros lisos en las olimpiadas de Río de Janeiro, y que Scott Reardon hizo un tiempo de 12,26 segundos en las mismas olimpiadas. Hice una pregunta muy facilita: ¿Quién lo hizo mejor? A pesar de ser muy obvio que había trampa, todo el mundo contestó al unísono que Usaín Bolt (que es realmente una pena que se haya retirado porque este tipo es marciano). Acto seguido desvelé la trampa: puse la foto de Scott Reardon que acompaña a este post y en la que podéis comprobar que le falta una pierna.

Efectivamente, Scott Reardon es un atleta australiano que compitió en Río 2016 en los 100 metros lisos. No sólo eso: ganó la medalla de oro. Si, con un tiempo de 12,26 ganó la medalla de oro en los 100 metros lisos en los juegos paralímpicos. Por tanto, corría en los 100 metros lisos, pero en una categoría diferente a Usain Bolt ¿Y por qué en una categoría diferente? Pues para que sea más fácil comparar peras con peras y manzanas con manzanas. Es más, si mis datos no me fallan en los juegos paralímpicos se puede competir en los 100 metros lisos en 16 categorías diferentes. Cada una de ellas tiene unas reglas muy claras sobre quién puede participar y cómo es la competición.

Este ejemplo sirve para ilustrar muy bien que, cuando se da una cifra, por sí misma no sirve de nada. Ya vimos algo parecido con el PUE: para poder valorarlo en su justa medida no basta con saber la cifra: también es necesario saber dónde se ubica el datacenter, a qué se dedica, etc: ya dijimos que no es lo mismo un datacenter para HPC en Noruega que uno para proceso transaccional de muy alta disponibilidad en el Sáhara. Con la disponibilidad sucede lo mismo: aunque todos tenemos claro lo que es, debemos definir excatamente a qué nos estamos refiriendo, y para esto tenemos que tener muy claras dos cosas:

  • La primera de ellas es si estamos hablando de disponibilidad especificada o medida. Por ejemplo, el estándar TIA-942 dice que si un DataCenter cumple con los criterios del nivel tres de la norma (Tier III) el datacenter tendrá una disponibilidad del 99,982% del tiempo. Es decir, la distribución estadística dice que si cumples con el nivel tres de la norma lo normal es que tengas esa disponibilidad, pero puede no ser así.
  • La segunda es el alcance de lo que llamamos disponibilidad ¿a qué nos referimos con disponibilidad del datacenter? ¿a la disponibilidad de las infraestructuras? ¿a la disponibilidad de las aplicaciones? Son aspectos que hay que precisar siempre. Si soy un proveedor de colocation me basta demostrar que las infraestructuras eléctricas y de refrigeración funcionan correctamente. Sin embargo, si soy un proveedor IaaS, me interesa demostrar que la plataforma está siempre disponible, y eso incluye no sólo a las infraestructuras del CPD, también a la granja de servidores y su almacenamiento, así como la capa de networking. Obviamente, al usuario le afecta toda la pila, desde la aplicación que está arriba de la pirámide al cuadro eléctrico de la entrada, pasando por servidores, almacenamiento, networking, enfriadoras, etc.

Yo siempre soy partidario de medir, porque la infraestructura mejor diseñada del mundo no sirve de nada si los procedimientos de explotación no son buenos. Así que, al igual que hemos hecho con el PUE, vamos a ver cómo medimos la disponibilidad: qué se mide, cómo se mide, etc. Eso lo veremos en la próxima serie de artículos. Mientras tanto, como siempre, si tenéis alguna duda poneos en contacto conmigo.

 

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 (III) – Cómo medir el PUE

[bws_linkedin display=»share»]

Hoy vamos a hablar de cómo medir el PUE. Como en los últimos años todo el mundo ha hablado hasta la saciedad del PUE puede parecer absurdo escribir un artículo sobre cómo medirlo. Pero no, os aseguro que no es absurdo: he comprobado personalmente que, aunque mucha gente hable del PUE, no sabe en realidad cómo debe medirse.

Esto es así porque mucha gente, en vez de hablar sobre mediciones reales, lo hace sobre estimaciones basadas en potencias nominales teóricas. La inmensa mayoría no es consciente de que el PUE real va a depender mucho de la carga y condiciones de explotación, de la misma forma que el consumo real del coche no se parece en nada al homologado, pues en el consumo del coche influirá la carga, la forma de conducción, tipo de carretera y un montón de factores más.

Medir el PUE no entraña ningún misterio ni dificultad. Lo único es que hay que tener claro es qué hay que medir y cómo hay que medirlo, y disponer de los medios técnicos para hacer las medidas.

Conceptualmente, The Green Grid define el PUE como el ratio entre la energía del DataCenter y la energía consumida por los equipos IT, es decir:

PUE = Total Facility Energy / IT Equipment Energy

Viendo la fórmula el concepto está clarísimo. Ahora, para realizar la medida de forma correcta hay que tener claras las respuestas a las siguientes preguntas:

  1. ¿Qué significa energía del DataCenter? ¿Es potencia activa o energía activa? ¿Y si es energía activa, de qué periodo es?
  2. ¿Dónde hay que tomar la medida consumo Total?
  3. ¿Dónde hay que tomar la medida consumo equipos IT.

Os puedo asegurar que, en función de cómo respondamos a esas preguntas, podemos obtener cifras de PUE muy dispares. Así que, para hacer las cosas bien, vayamos a las definiciones dadas por TGG.

Para entender mejor las cosas, empecemos por lo conceptualmente más fácil, que es el consumo de los equipos IT. El alcance es sencillo de determinar: servidores, sistemas de almacenamiento, componentes de red, etc. Pero ¿dónde realizamos la medida? Hay tres posibilidades:

  1. A la salida de la(s) UPS. Fácil en la mayoría de los casos, basta con que la UPS disponga de algún sistema de monitorización, normalmente SNMP. En este caso el consumo IT sería la suma de los consumos a las salidas de las UPS. Por ejemplo, si hay dos UPS, el denominador de la ecuación del PUE será la suma del consumo a la salida de las dos UPS.
  2. A la salida de las PDU’s. Para esto hace falta disponer de PDU’s monitorizables. Si no las tenemos, es posible instalar pequeños monitorizadores en cada una de las líneas que vayan a las PDU’s (lo podemos conseguir por unos con muy bajo coste por PDU, si queréis preguntadme). El consumo IT será la suma del consumo de todas las PDU’s. Como es obvio, es necesario que todas las PDU’s estén monitorizadas. Si tenemos diez PDU’s pero sólo monitorizamos ocho, estamos dejando de sumar dos en el denominador y el PUE que obtendremos será más alto del real.*
  3. A la entrada de los equipos IT: requiere que cada enchufe de cada equipo IT esté conectado a un enchufe inteligente que monitorice la energía. Puede hacerse también a bajo coste (preguntadme de nuevo).

Bien, ya sabemos dónde hay que medir los consumos de los equipos IT. La siguiente pregunta es qué hay que medir. Parece una pregunta tonta, pero no lo es. Lo que hay que medir es energía activa (kWh) como si fuera un simple contador eléctrico. He visto algunas instalaciones en las que se mide potencia activa y se realizan los cálculos para conseguir la energía activa. Esto sólo es fiable si la frecuencia de muestreo es alta, y por eso la especificación dice que hay que utilizar energía activa.

Si ya sabemos las respuestas a las preguntas ¿dónde hay que medir? Y ¿qué hay que medir?, la siguiente es el cuándo. Es decir, cuándo tenemos que tomar las medidas o, mejor dicho, cada cuánto tiempo tenemos que tomar las medidas. La respuesta básica a esta pregunta es lo más a menudo que sea posible. Lo ideal sería que pudiéramos tomar medidas cada cinco minutos o, en su defecto, cada cuarto de hora como en el sector eléctrico.

Lo que es muy importante es tener en cuenta que el PUE es un año de medidas. Es decir, si quiero dar una medida sencilla pero real del PUE, lo que tengo que hacer es poner un contador eléctrico para que mida el consumo total, otro para que mida el consumo IT, esperar un año, ver los kWh consumidos y hacer la división.

¿Por qué un año? Para que la medida sea real. Si realizamos un muestreo frecuente, podremos ver momentos en el que la medida del PUE es muy buena y otros en las que es muy mala. Es decir, si en vez de tomar un año completo tomo sólo una hora, por ejemplo entre las seis y las siete de la mañana de un día de invierno en el que todo el datacenter esté refrigerado mediante freecoling y además por casualidad tengo todos los equipos IT al 100% de carga… me saldrá un PUE buenísimo, pero no es un PUE válido. Pero son necesarias: estas medidas parciales del PUE nos serán muy útiles para aprender las diferentes condiciones de explotación que tiene nuestro DataCenter y cómo tomar medidas para mejorarlas, y así conseguir que la medida global sea mejor.

Hasta aquí lo referente al consumo IT. Pero ¿y el consumo total? (Total Facility Energy) ¿Dónde se mide? Mucha gente lo está midiendo en el cuadro principal del DataCenter, es decir, además del consumo IT miden consumo de refrigeración, UPS, switches de transferencia, etc. ¡Pero esta medida es incorrecta! Si miramos la definición en inglés que hace TGG, el numerador es Total Facility Energy. Y el significado de Facility, en este caso, no es sólo la sala de ordenadores. El significado es El Centro de Proceso de Datos y todo lo necesario para que funcione. Es decir, que hay que añadir el consumo de los humanos que hacen que el tinglado funcione. Quizá la expresión no sea la adecuada, porque hay técnicos de sistemas que aunque tengan DNI no parecen humanos y probablemente no hayan nacido en este planeta, pero el consumo eléctrico que genera su trabajo hay que tenerlo en cuenta.

Así, si una organización tiene un edificio en el que se alberga el CPD y la gente del departamento de sistemas, Total Facility Energy significa Consumo del Edificio, que obviamente incluye la calefacción de los despachos de los informáticos, su iluminación, PC’s, etc. Esto tiene consecuencias:

  1. Es fácil de calcular si existe un edificio dedicado al CPD y su personal, pero en los casos mixtos (edificios que sólo son parcialmente dedicados al Centro de Proceso de Datos) hay que determinar qué parte corresponde a Total Facility Energy y es fácil cometer errores.
  2. Evidentemente, el consumo del numerador será mayor si se tiene en cuenta el verdadero significado de Total Facility Energy y, por tanto, el PUE será peor que si se calcula únicamente con la energía de la sala de ordenadores. Por eso podemos afirmar sin dudar que muchas de las cifras de PUE oídas en conversaciones de café son inventadas o simplemente están mal medidas.
  3. Un CPD mediano puede necesitar x técnicos de sistemas y un CPD grande puede necesitar el mismo número de técnicos de sistemas, así que incrementa más todavía las economías de escala entre CPD’s pequeños y grandes.

Recapitulando, hemos visto que TGG propone diversos puntos de medida, así como frecuencias diferentes para tomarlas. Eso es porque podemos hablar de tres categorías de PUE (Básico o L1, Intermedio o L2 y Avanzado o L3). Así que no vale con decir mi PUE es X. Deberíamos decir Mi PUE LY es X, donde Y es la categoría del PUE que hemos medido. A continuación tenemos el cuadro resumen:

Medida PUE Básico (L1) PUE Intermedio (L2) PUE Avanzado (L3)
Consumo IT Salida de las UPS Salida de las PDU’s Entrada equipos IT
Consumo Total Entrada del CPD1 Entrada del CPD1 Entrada del CPD1
Frecuencia de lectura Mínimo: mensual

Ideal: semanal

Mínimo: diario

Ideal: cada hora

Mínimo: 15 minutos

Ideal: 5 minutos

Este artículo ha salido el doble de largo de lo habitual en el blog, y aun así podría extenderse mucho más. Así que ya sabéis, quienes tengáis dudas después de leer el artículo, queráis ayuda para montar un sistema de medición en tiempo real, saber qué dispositivos son los más adecuados para montar un sistema de medición sin romper el presupuesto, etc, contactad conmigo.

 

1 Ver las consideraciones sobre lo que significa Entrada del Edificio.

Data Center, Infrastructure & Operations Management Summit (II)

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.