Seleccionar página

OSDA – Open Standard for DataCenter Availability (II)

martes, 14 Nov PM | Big Data, Datacenter, Eficiencia Energética, Métricas

En el artículo anterior dijimos que los estándares de diseño que han imperado durante muchos años ya no dan respuesta a las necesidades de hoy en día, y en este artículo vamos a ver por qué. Así que tras un pequeño parón para cambio de servidor,  volvemos a la carga con el OSDA.

Pero ¿por qué tenemos que redefinir estas cosas? ¿No es reinventar la rueda? Pues no, y no lo es fundamentalmente por dos razones:

  • La primera es que las normas están diseñadas para un modelo IT clásico, es decir On Premise, en el que cada organización es dueña de sus infraestructuras y las explota. Es evidente que en este modelo de funcionamiento el DataCenter es una infraestructura crítica para la organización, sobre todo si hiciéramos una encuesta y nos diéramos cuenta que lo de tener un CDP de respaldo es menos frecuente de lo que pensamos y, en todo caso, más reciente de lo que pensamos. Es decir, hasta ahora ha imperado el paradigma Juan Palomo: la organización es propietaria de sus infraestructuras iT y se encarga de explotarlas, así que esas infraestructuras, al ser críticas, deben ser lo más fiables posible. Si puedo Tier 3, pues Tier 3. Y si el bolsillo me da para TIer 4, pues Tier 4. Y, el que podía, un CPD alternativo, pero esto último en empresas pequeñas y medianas se ha limitado en la mayoría de los casos a hacer copias de seguridad y llevarlas a casa. Puede parecer absurdo, pero puedo hacer una lista con más de 100 organizaciones que están todavía así. Organizaciones públicas y privadas, grandes y medianas empresas, comunidades autónomas, ayuntamientos de más de 100.000 habitantes (una de las peripecias de mi vida fue diseñar el rescate informático de un ayuntamiento al que se le quemó su único CPD), universidades, etc, etc. Las implicaciones son evidentes: como sólo tengo un coche, necesito que sea duro y fiable, así que no me importa que sea costoso y feo. Es el modelo Volvo aplicado a IT: si puedo, me compro un segundo coche por si las moscas. Si me puedo permitir dos Volvos, me compro dos Volvos. Y si el segundo es un Pandita, ni cabrá toda la familia, ni iremos igual de seguros ni llegaremos tan lejos, pero siempre será mejor que nada.
  • La segunda son los Dogmas de Fe que existen en el mundo IT, y el datacenter no sólo no es ajeno a tener dogmas sino que a durante años se ha quemado en la hoguera a los herejes que pensábamos que quizá mereciera la pena echarle una pensada a algunos conceptos, por si hubiera alguna forma diferente para hacer las cosas de una forma más eficiente. Podríamos citar muchos de estos dogmas de fe. Pero, por ejemplo: la electricidad es un servicio que se contrata a una compañía eléctrica, y si quieres que te diseñe un sistema fiable de suministro eléctrico para tu datacenter tendrás dos contratos de suministro con dos compañías diferentes y te tendrán que llegar dos líneas diferentes de dos subestaciones diferentes. Está claro que el que piensa así tiene acciones de las compañías eléctricas. Podríamos seguir con más dogmas sobre electricidad, refrigeración, etc. Por cierto, recuerdo que cuando hace diez años hicimos el CPD de Caléndula y contaba que utilizábamos intercambiadores de calor aire/agua en el CPD mucha gente me miraba con más repelús que a los extraterrestres de Men in Black. Ahora, las soluciones InRow aire/agua están a la orden del día. Muchas de las soluciones que aplicamos entonces y que fueron muy innovadoras ahora están a la orden del día. Eso si, diseñamos armarios capaces de albergar 40kW, y a día de hoy no he visto ningún otro CPD capaz de eso.

Si nos fijamos, ambos puntos encierran una gran contradicción: las Tecnologías de la Información y las Comunicaciones son muy innovadoras, y han sido la tecnología disruptiva que han provocado grandes cambios sociales y económicos en los últimos 50 años. Sin embargo, las TIC son reacias a la innovación. Es más, en el mundo del DataCenter no sólo no se ha fomentado la innovación sino que, en buena medida, se ha penalizado. Si nos fijamos, en las normas existentes no caben energías renovables, autoconsumo, otros modelos de refrigeración, etc. Es evidente que una norma no puede prever qué tecnologías van a aparecer en los próximos años, pero sí puede prever cómo incorporarlas.

Así que este es uno de los objetivos del OSDA: no sólo hay que utilizar la tecnología que hay disponible hoy en día, también es necesario fomentar la innovación e incorporarla al proceso. Y esto empieza por las definiciones de base. La primera es que si yo soy el CTO de mi organización debo diseñar infraestructuras para dar respuesta a las necesidades de disponibilidad de mi organización, y ese diseño debe ser global. Es decir, romper ese paradigma en el que un CPD es una mónada aislada del Universo. Por ejemplo, qué es mejor: ¿un único CPD a prueba de bombas o tener la carga en dos o tres CPD’s low cost en un modelo activo/activo? Como hemos dicho en artículos anteriores, tenemos que tener en cuenta que los Centros de Proceso de Datos existen para ejecutar aplicaciones, así que lo verdaderamente importante es que funcionen estas últimas.

Lo importante es diseñar infraestructuras que den respuesta adecuada a las necesidades. Y dar respuesta adecuada significa, como decíamos al principio, pensar sobre el problema que tenemos que resolver y cuál es la mejor forma de resolverlo, abstrayéndonos de dogmas. Incluso los que hoy en día defienden modelos On Premise -sigue habiendo mucha gente que se aferra a ellos- que sin darse cuenta han ido externalizando el correo amén de otras muchas cosas, así que tienen que asumir que los modelos de Cloud Híbrida están a la orden del día.

En el próximo artículo entraremos en materia del OSDA. Mientras tanto, ya sabéis: si queréis implantar metodologías y métricas en vuestro CPD, contactad conmigo.

 

Conceptos básicos de disponibilidad (II)

martes, 17 Oct PM | Datacenter, Métricas

[bws_linkedin display=»share»]

En el artículo anterior vimos que podemos abordar la disponibilidad en tres momentos distintos. Ahora hay que hablar del de qué. Es decir, tenemos que definir muy claramente a qué recurso nos referimos cuando decimos la disponiblidad es 99,998%. Ya lo hemos dicho anteriormente, dependerá de quién seamos y qué hagamos: un DataCenter que preste servicios de housing querrá demostrar que es capaz de mantener los racks en condiciones operativas un determinado porcentaje de tiempo.  Esto es muy importante en función de cuál sea el alcance de la responsabilidad de cada uno: el rack puede estar perfecto, pero si la aplicación está colgada hay un problema. Hay que tener en cuenta que en el mundo cloud moderno, la pila IT puede tener diversos responsables: uno para las infraestructuras de datacenter, otro para la plataforma hardware y networking, otro para el software, etc. Para cada uno de ellos, el concepto disponibilidad tendrá un alcance diferente en función de cuál sea el recurso en cuestión.

Por esta razón es muy importante que cuando hablemos de disponibilidad delimitemos bien su alcance, es decir, el de qué. Pero, también hay que definir con precisión disponible, o lo que es lo mismo, cómo vamos a medir la disponibilidad. Como la mayoría de los técnicos de sistemas saben, una de las herramientas más utilizadas para monitorizar disponibilidades ha sido Nagios. Es software libre y fácil de utilizar, aunque sus ficheros de configuración son farragosos. Nagios ha tenido la gran virtud de extender la monitorización, y muchos sitios se han empezado a monitorizar gracias a Nagios (o lo que es lo mismo, sin Nagios no se hubieran monitorizado, lo que es terrible). Pero Nagios está muy orientado a monitorizar utilizando «pings», con un algoritmo muy sencillo: si responde, está vivo. Este es el método que muchos utilizan para comprobar la disponibilidad, pero no tienen en cuenta que vivo no es lo  mismo que disponible. Muchas veces los dispositivos responden al ping, pero no están disponibles. Le hago ping al servidor web y el servidor responde, pero eso no significa que el servidor esté bien.

Por eso hay que definir con precisión qué significa estar disponible, y esto es la letra pequeña del SLA. Si seguimos con el ejemplo del servidor web, podríamos decir algo como: se comprueba mediante un comando HTTP GET que el servidor responde, que devuelve la página principal comprobando con el patrón que no ha sido modificada por un hacker y que la respuesta se produce en menos de x milisegundos. Aquí podemos ser tan barrocos como queramos, comprobando todo el árbol web o no, controlando desde el tiempo de respuesta a la introducción de datos en formularios, etc.

Bien, pues esto hay que hacerlo independientemente del alcance. Traslademos el ejemplo del web a un prestador de servicios de housing. En este caso, el SLA hará mención de las infraestructuras: Cada rack dispondrá de alimentación de 220V con una capacidad de 32A (o 16, o 64, o 96 o lo que corresponda), con una temperatura inferior o igual a…, etc., etc.

En resumidas cuentas, cuando medimos disponibilidades tenemos que leer la letra pequeña del SLA a que nos hayamos comprometido y adoptar las medidas técnicas para poder demostrar fehacientemente con medidas que estamos cumpliendo nuestra parte.  En este punto, hay quienes optan por SLA’s poco claros en los que no se explicita con precisión el alcance del servicio que se presta. Bien, esto es un gran error estratégico: si lo hacemos así en cuanto haya discrepancias no podremos demostrar que estamos cumpliendo y, como el cliente o el usuario siempre tienen la razón, tendremos problemas.

En resumen, el problema de la disponibilidad lo debemos abordar en tres momentos:

  1. Al establecer el Acuerdo de Nivel de Servicio (SLA) que prestaremos a nuestros clientes y/o usuarios: ya dijimos que siempre debemos tener explicitado el SLA aunque trabajemos para nuestra propia organización.
  2. Al diseñar las infraestructuras y sistemas que utilizaremos para prestar los servicios.
  3. Una vez que están los servicios en producción deberemos realizar medidas reales para poder corroborar con datos que estamos cumpliendo nuestra parte del trato.

Transversalmente a estas etapas debemos dejar clara la definición de recurso y la definición de disponible, pues juntas forman el alcance de los servicios que vamos a prestar.

¿Es esto todo? ¡No, se escapa un pequeño detalle! Este detalle es el concepto novedoso del que os hablaba en el artículo anterior y que explicaré con profundidad en el próximo artículo.

 

 

 

Conceptos básicos de disponibilidad (I)

martes, 10 Oct PM | Datacenter, Métricas

[bws_linkedin display=»share»]

En muchas ocasiones, al acercarnos a alguna materia, damos por sentados los conceptos básicos. No nos atrevemos a preguntar, los intuimos y resulta que la base de todo no la tenemos clara. Es evidente que no se puede levantar un pilar resistente sin una zapata sólida. Esto pasa con cualquier área de conocimiento, y las TIC no son ajenas a este fenómeno. Es más, por lo que he podido comprobar en mis muchos años dedicados a esto, es algo que se da con mucha frecuencia. Sobre todo cuando se introducen conceptos o tecnologías novedosas: se ponen de moda y para no quedar como pardillos actuamos como si los conociéramos de toda la vida aunque no tengamos claro de qué van. Un ejemplo de esto es el consabido PUE, que como ya hemos explicado en artículos anteriores, hemos oído a mucha gente hablar de PUE sin un conocimiento preciso de qué es.

Pero algunos habéis vencido estas reticencias, y me habéis pedido que amplíe el último artículo y aclare los conceptos básicos sobre disponibilidad. Así que en ello estamos, en explicar con un poco más de rigor esos conceptos básicos.

Así que vamos a hablar de disponibilidad en dos ejes: el de ¿disponibilidad de qué? y el de ¿disponibilidad de qué tipo?.  Así que en este artículo vamos a hablar del ¿Disponibilidad, de qué?, y para ello vamos a intentar definir disponibilidad. Recordad que en el artículo anterior vimos que ante la pregunta de qué es, mucha gente contesta ¡qué pregunta más tonta! Disponibilidad es… disponibilidad!. Bueno, pues según el diccionario de la Real Academia de la Lengua, en su primera acepción, disponibilidad es cualidad o condición de disponible. Aplicado a las TIC, vamos a dar una definición formal de disponibilidad:

Disponibilidad es el porcentaje del tiempo en el que un recurso está disponible.

Pero como lo que hace un datacenter y un servicio TIC, es precisamente eso, prestar un servicio, hay que hablar de disponibilidad en tres momentos diferentes:

  1. El primero de ellos es del de la determinación del acuerdo de nivel de servicio (SLA) del datacenter o del servicio IT en cuestión. Quienes prestan servicios para terceros o tienen una ISO 20000 en vigor esto lo deberían tener claro, pero hay datacenters medianos que prestan servicio a una única organización que no tienen un SLA bien definido con su propietario. Da igual que sea un ayuntamiento, una universidad, una mediana empresa o quien seas: si eres un datacenter o si prestas servicios IT, aunque sólo sea a tu organización, tienes que tener obligatoriamente un SLA. Este SLA es la disponibilidad del servicio que prestas: así que esta es la primera fase en la que hay que hablar de disponibilidad: la del compromiso de calidad de servicio. Por ejemplo, te voy a prestar el servicio X y va a estar disponible el 99% del tiempo. Es decir, es el requisito de disponibilidad.
  2. La siguiente fase es obvia: si me he comprometido a una determinada disponibilidad tendré que diseñar mis infraestructuras y sistemas para poder cumplir eso. Para no dar palos de ciego en este reto, existen ayudas para ello. Por ejemplo, la norma TIA-942 establece cuatro niveles de requisitos técnicos, y lo que dice es «si cumples el nivel de requisitos X tu disponibilidad será del Y%». Obviamente esto es una distribución estadística. La probabilidad de que tú tengas un póker y tu rival tenga una escalera real es muy baja, pero puede suceder. Si se cumplen los estándares del nivel 4 de la TIA-942 se supone que se conseguirá una disponibilidad del 99.995%, pero la realidad puede ser diferente. En cualquier caso, la norma TIA-942 y similares son un buen punto de partida para diseñar unas infraestructuras capaces de cumplir con el requisito de disponibilidad. Es decir, esta etapa es la del diseño, la de la especificación de disponibilidad.
  3. Por último, toca demostrar que gracias que la especificación ha sido la correcta, estamos cumpliendo con el requisito. Es decir, toca comprobar en tiempo real la disponibilidad y guardar los resultados históricos para poder utilizarlos cada vez que haga falta. Esto debe hacerse de forma que no permita controversia. Es más, puede suceder que mi cuello dependa de ello (o pleitos millonarios, y si se pierden mi cuello también peligra). Es la tercera fase: la de medir la disponibilidad.

En resumen, ya sabemos que tenemos que hablar de disponibilidad en tres momentos: en de establecer los requisitos del servicio, el de especificar las infraestructuras y el de medir el resultado de explotación.

Pero ¿es esto suficiente? ¡No! Quedan dos cosas: definir con precisión qué es un recurso y definir con precisión qué significa disponible. Esto lo haremos en los próximos artículos, en el que además de de hablar de esto os introduciré algún concepto innovador que llevo tiempo utilizando. Mientras tanto, ya sabéis: si tenéis dudas o queréis implementar algún sistema de control, contactad conmigo.

 

 

¿Qué es la disponibilidad?

martes, 3 Oct PM | Datacenter, Métricas, Uncategorized

[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

martes, 26 Sep PM | Cloud Computing, Datacenter, Eficiencia Energética, HPC, Métricas, Uncategorized

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