Seleccionar página

¿Qué es la disponibilidad?

¿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

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.

¿Cloud híbrida, yo? ¡Ja!

El otro día estuve tomando un café con dos buenos amigos que son directores de sistemas de sus respectivas organizaciones. Director de sistemas: esa cosa tan española en la que mezclamos CIO y CTO en una especie de dos por el precio de uno. Trabajan en  organizaciones grandes y dan servicio, cada uno, a más de 5.000 usuarios.

En medio de una charla distendida, les pregunté ¿qué planes cloud tenéis para vuestras organizaciones? La pregunta era totalmente inocente sin ninguna intención de polemizar. Simplemente es un tema de charla más, y siempre me gusta preguntar qué hace la gente y qué soluciones dan a los problemas, pues se amplía el campo de visión y se aprende mucho.

Lo que realmente me sorprendió fuie la respuesta que ambos dieron, casi al unísono, y que puede resumirse en ¿cloud? ¿en mi organización? ¡jamás de los jamases! Por supuesto, la respuesta fue acompañada con unas caras de sorpresa y estupor que parecía que les había preguntado si consumían heroína. A continuación, ambos me soltaron un largo discurso en el que, en líneas generales, decían lo mismo: el cloud no es adecuado para mi organización porque bla, bla, bla. (el cúmulo de razones era tan prolijo que no os voy a aburrir con ellas).

Cuando terminó la avalancha de explicaciones y justificaciones (que más parecían una regañina) yo seguí a lo mío: meterme en la boca del lobo: vale, pero ¿ni siquiera os planteáis los beneficios que os puede dar un esquema híbrido? Insensato de mí, me cayó otro chorreo.

Al cabo del rato, y con las aguas más calmadas, la charla derivó a derroteros más tecnológicos: la dificultad de integración con el LDAP corporativo para que funcione el correo de Google, las dificultades de que SalesForce se integre bien con el resto de aplicaciones, etc.

Oye, me estáis contando que ya tenéis el correo en la nube, CRM, ficheros, aplicaciones ofimáticas ¿por qué decís que nunca usaréis nubes híbridas? ¿Esas aplicaciones y el proceso de integración con el resto de sistemas corporativos qué son? Queridos, vosotros tenéis una cloud híbrida con todas las de la ley… y ni os habéis enterado.

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.

Data Center, Infrastructure & Operations Management Summit (I)

Este mes tenía la agenda repleta de eventos, el último en el que he estado es el Data Center, Infrastructure & Operations Management Summit. Londres siempre merece la pena, y el evento, también. En otro post os hablaré en más detalle del evento, ahora sólo quiero dejar dos detalles.

El primero, una frase que me ha gustado mucho. En la profesión hay un viejo chascarrillo: Legacy is all that works. Pero en la keynote de apertura, a cargo de Neil Rickard y Milind Govekar, dijeron una frase que me encantó y con la que no puedo estar de acuerdo: Don’t be a Custodian of Legacy Technologies. Llevo años diciendo eso mismo: si no provocas tú el cambio, te pasará por encima, así que espabilad.

Un evento con más de mil personas en el que sólo estábamos media docena de asistentes españoles: tenemos que hacérnoslo mirar. Y hay otra cosa que nos tenemos que hacer mirar: en dos días he estado en 19 charlas, y todos los ponentes terminaban a la hora en punto sin necesidad que que un moderador les interrumpiera. Y más significativo aún: no sonó ni un puñetero móvil. Salas con 300 personas y no sonaba ni un móvil. Para terminar de descentrar, no había ningún runrun de gente charloteando. Hombre ¿cómo se va a concentrar uno en lo que te están contando si no suenan móviles, la gente no hace ruido y encima el ponente termina a la hora?

Casi igual que el evento en el que estuve el viernes en Madrid, en el que los ponentes que nos ajustamos a nuestro tiempo fuimos excepción y en el que sonaba un móvil cada dos por tres.

Por lo demás, Boris Becker muy simpático y el O2 Arena muy bonito, unas vistas impresionantes y te hace recordar la peli de Pierce Brosnan, pero excesivamente apartado.