Seleccionar página

Nace www.top500.es

Ayer, tuve una participación en el evento Grandes infraestructuras tecnológicas en la nueva era digital: Eficientes energéticamente y sostenibles (una vez más enhorabuena a Óscar Azorín y su equipo por una organización perfecta). En concreto, participé en la primera sesión, que tenía por título Supercomputación: liderando la sostenibilidad en la nueva era digital. Mi participación la titulé Supercomputación, métricas y eficiencia.

En la primera parte de mi intervención, conté la iniciativa www.top500.es. El propósito es crear un portal con la lista de los 500 sistemas de cálculo más potentes de los países de habla hispana. Algunos os preguntaréis el por qué de esta iniciativa, que a surgido a raíz de un trabajo que he tenido que realizar en los últimos meses: ayudar a un Centro de Supercomputación a diseñar su estrategia, la arquitectura del nuevo sistema que van a adquirir y cuál es la mejor forma de reformar el datacenter para alojarlo.

Como es lógico, en un trabajo de consultoría de este tipo una parte importante para diseñar la estrategia es plasmar “la foto” del ecosistema español de supercomputación, y eso requiere saber qué es lo que hay. Evidentemente, conozco todos los sistemas que forman parte de la Red Española de Supercomputación, de cuyo Consejo formé parte hasta mediados de junio del año pasado. También conozco algunos otros sistemas. Pero la realidad es que, en España, hay una potencia de cálculo relevante  en sistemas departamentales y empresas privadas que no son conocidos. Es decir, que no sabemos el inventario que tenemos como país de una infraestructura cara y necesaria. Los superordenadores son obviamente caros, pero también son necesarios. En casi todos los campos es necesario “computar para competir”.

Esta carencia de información sobre cuántos sistemas de cálculo hay en España y cómo son la he comentado en ocasiones con otros directores de centros de supercomputación, así como la necesidad de conocerlos para optimizar mejor un recurso caro y escaso. Por eso, a raíz del trabajo de consultoría y del trabajo de investigación que tuve que hacer para realizarlo, se me ocurrió la idea de crear el equivalente a top500. La iniciativa fue muy bien acogida, y nos pusimos en marcha para crear www.top500.es.

La vocación de www.top500.es es ser el portal de referencia en supercomputación para los países de habla hispana. Los motivos que nos mueven son:

  1. Saber qué sistemas hay para que se puedan optimizar los recursos.
  2. Concienciar a los gobiernos de España y resto de países de hispanoamérica de la necesidad de invertir en supercomputación. La lista top500 de noviembre de 2018 debería sonrojarnos. En la lista aparecen 227 ordenadores de China, 109 de EEUU, 94 de Europa y 31 de Japón. A los 94 de Europa, España sólo aporta uno: el Mare Nostrum. La comparación con Francia (18 ordenadores en la lista) e Italia (6 ordenadores en la lista) debería sonrojarnos. Pero si miramos que en la misma lista Arabia Saudí (donde el Free Cooling no está muy fácil) tiene 3, se nos debería caer la cara de vergüenza como país. Por tamaño, España debería tener tres o cuatro ordenadores en la lista. ¿Por qué el CESGA, Scayle o Computaex no disponen del dinero necesario para entrar en la lista?.
  3. Generar conocimiento. La lista top 500 da muy poca información, Rpeak, Rmax, número de cores y, desde hace unos pocos años, energía. En top500.es pretendemos recabar mucha información de cada sistema para poder analizarla utilizando técnicas de machine learning y generar conocimiento con ella.

Os pido que apoyéis a www.top500.es, una iniciativa completamente sin ánimo de lucro, para apoyar y ayudar a la supercomputación en España y países de habla hispana. La supercomputación es una herramienta importantísima para el progreso de la ciencia y la tecnología.

 

OSDA – Open Standard for DataCenter Availability (I)

[bws_linkedin display=”share”]

Durante muchos años, los estándares de instituciones como el Uptime Institute, TIA y BICSI han sido ampliamente utilizados en diseño, construcción y operación de DataCenters. Son sencillos y relativamente fáciles de utilizar, y su primer objetivo es facilitarnos una clasificación básica sobre datacenters. Cada uno de ellos tiene sus peculiaridades, pero básicamente marcan los requisitos para tener cuatro categorías de centros de proceso de datos. Estas cuatro categorías tienen pequeñas diferencias entre unos estándares u otros, pero podríamos hacer una descripción somera de ellas así:

  1. Básico y no redundante: el nivel más básico no tiene elementos redundados, por lo que en caso de fallo de un componente crítico se producirá una parada. (el responsable de explotación no pega ojo)
  2. Básico redundante: los componentes críticos están redundados. (el responsable de explotación necesita una dosis fuerte de pastillas para dormir).
  3. Mantenimiento concurrente: se puede hacer mantenimiento de cualquier componente sin necesidad de parar o degradar servicios. (el responsable de explotación baja la dosis de pastillas en invierno)
  4. Tolerante a fallos: el CPD es completamente tolerante a fallos. (el responsable de explotación duerme a pierna suelta)

Los estándares marcan unos requisitos de diseño y constructivos para encuadrarse en cada una de las categorías y, si se cumplen, como consecuencia se tendrá una tasa de disponibilidad conocida de antemano. Si las políticas de explotación se adecúan a las buenas prácticas, estadísticamente deben cumplirse las tasas de disponibilidad especificadas en la norma. Durante años, estos estándares han sido muy útiles.

Pero ¿y hoy en día? ¿Son suficientes? Claramente no, y en este artículo vamos a ver por qué. Estos estándares están diseñados para un paradigma en el que cada organización tenía su centro de proceso de datos y, si la organización se lo podía permitir, uno alternativo. Es decir, estas normas asumen que una organización tiene un centro de proceso de datos propio, en el que tiene toda su producción. Como es evidente, este datacenter es crítico, y debe estar diseñado de forma robusta. Si me lo puedo permitir hago un datacenter que resista una bomba atómica, y si soy más pobretón con una o dos UPS me vale.

La informática es crítica para una organización. Si la informática se para entonces la organización se colapsa, así que tiene que funcionar sí o sí. Por eso, durante muchos años, por favor, me ponga usté un host mu caro o lo mejor que haiga y no repare en gastos. Los sistemas eran carísimos y el software tanto como el sistema o más: el coste de los mainframes y sus licencias convertían en irrisorio el coste de la electricidad, las UPS’s, las enfriadoras y demás martingalas necesarias.

Pero claro, para que funcione el host y su software, el router y todas esas puñetas hacen falta cosas básicas: electricidad y frío. Para esto las soluciones han permanecido invariables durante muchos años: en la electricidad un suministro de luz (o dos para los ricos) contratado a una compañía eléctrica. Por si falla el suministro, uno o más sistemas de alimentación ininterrumpida. Y para cuando se agoten las baterías, uno o varios generadores diesel. En el lado del frío, cacharros que generaban frío a base de compresores, se enfriaba el aire y ese aire frío se echa debajo del falso suelo. Por si las moscas, se ponen más cacharros de frío de los necesarios. Por cierto, que el viejo sistema de refrigeración por impulsión por falso suelo es un ejemplo del despilfarro energético que ha caracterizado al mundo del datacenter, porque hacerlo así es como encender el aire acondicionado del dormitorio para refrigerar el salón.

Por eso los estándares que hemos mencionado hablan explícitamente de este tipo de infraestructuras. Pero hoy en día las cosas son diferentes por muchos motivos. Uno de ellos es que tenemos un abanico de soluciones mucho mayor, y el otro es que desde hace tiempo el precio del kWh sube más que las angulas en navidad. Así que uno de los parámetros que hay que tener en cuenta en las tres fases del datacenter que hemos detallado al principio, esto es, el diseño, construcción y explotación, es el de la eficiencia, y el problema es que los estándares mencionados no contemplan para nada la Eficiencia (escrito así, con mayúsculas, como debe ser).

Para suplir esta carencia The Green Grid ha propuesto el Open Standard for DataCenter Availability (OSDA). Tal como el propio TGG indica, uno de los objetivos al proponer el OSDA es fomentar la innovación, teniendo como metas la sostenibilidad y la Eficiencia Energética. En esta serie de artículos veremos los principios básicos del OSDA y cómo utilizarlo. Y ya sabéis, si tenéis dudas o queréis averiguar el estado real de vuestro datacenter, contactad conmigo.

 

Disponibilidad y lógica difusa

[bws_linkedin display=”share”]

En el artículo anterior dijimos que es imprescindible controlar la disponibilidad, y que es imprescindible hacerlo para poder demostrar de forma fehaciente que estamos cumpliendo el Acuerdo de Nivel de Servicio que tenemos comprometido. Esto, independientemente de que su comprobación sea muy sofisticado o no, es, en principio, binario. O es sí o es no. Mejor dicho, como la carga de la prueba recae siempre por el lado del prestador del servicio, si no es sí tenemos un problema. Es decir, que si no podemos demostrar que estemos cumpliendo, da igual que en realidad lo estemos haciendo: si no podemos demostrarlo tenemos un problema.

Supongamos que estamos midiendo nuestra disponibilidad tal como hemos dicho y que somos capaces de demostrar que estamos cumpliendo ¿Es esto todo o deberíamos ir un poco más allá? En mi opinión, esto no es bastante. Si queremos conservar nuestro cuello, es necesario que sepamos a qué distancia estamos del desastre.

Como uno es persona de ideas peregrinas, a veces cuando voy en un avión sentado al lado de la ventanilla pienso aquí se va muy cómodo (con el espacio entre asientos de hoy en día, es un decir) pero si estuviera un metro más allá... Vale, quizá el ejemplo no es muy bueno, está el fuselaje en medio. Pero la idea se entiende: a veces nos separa muy, muy poquito del desastre, y para que no suceda ese desastre lo ideal es saber a qué distancia nos encontramos de él.

Si uno se sube a la azotea de un edificio de 50 plantas siempre se corre el riesgo de caerse. Corremos riesgos al estar en alturas, al ir en coche y, prácticamente, en cualquier actividad que hagamos: la vida es riesgo. Pero sigamos con el ejemplo de la altura, porque de la misma forma que a la mayoría de las personas les dan vértigo las alturas, a la mayoría de los técnicos de sistemas les da vértigo una caída grave de servicio en la que los teléfonos echan humo.

Supongamos que mi vida es la disponibilidad, que cumplo mi SLA humano si estoy vivo. Salgo a la azotea y me quedo en el centro, lejos del borde. Hombre, en principio parece bastante seguro. Puede suceder que venga una racha huracanada de viento, arrastre mis casi cien kilos y me tire por el borde de la azotea. Puede suceder, pero es altamente improbable. Sin embargo, si voy caminando por la azotea el riesgo de caer por el borde es cada vez mayor. A menos de un metro el riesgo de tropezar y caer por la barandilla es mayor que si estoy a diez metros. Y si me subo al borde de la barandilla, mientras esté ahí estaré vivo. Pero la probabilidad de que un resbalón o una pequeña ráfaga de viendo me hagan caer es enorme, y si eso sucede, adiós a mi disponibilidad, y en este caso, para siempre.

Para prevenir esto deberíamos utilizar un sistema de lógica difusa: cuanto más cerca estoy del borde menos disponibilidad tengo. Mientras esté en la azotea, perteneceré al conjunto de los disponibles, pero si me quedo en el centro perteneceré más que si me acerco al borde, y si me caigo por el borde dejaré de pertenecer al conjunto de los disponbiles. Como veis, son los conceptos básicos de lógica difusa.

¿Cómo aplicamos todo esto a nuestro servicio IT? Bueno, pues el concepto es sencillo. Ponerlo en marcha no lo es tanto. Supongamos que tenemos un servicio. Uno y sólo uno, que no es cosa de cansarse, pero es un servicio que es crítico y nos han puesto un SLA exigente. El servicio no requiere mucha carga computacional, pero es crítico (por ejemplo, el DNS: consume poco, pero cuando no funciona arde Troya. Así que nos curamos en salud y lo ponemos todo redundado: dos servidores con dos fuentes de alimentación cada uno, dos sistemas de almacenamiento don dos controladoras cada uno, dos switches, dos sistemas de alimentación ininterrumpida, dos enfriadoras, dos técnicos de sistemas, dos cafés, etc, etc. Todo redundado por si las moscas.

Supongamos que tengo un sistema para medir el SLA que comprueba que el DNS está en marcha, responde, lo hace dentro de la latencia especificada, etc, así que queda registro de Si, está disponible. Y ahora se van produciendo averías hardware. Empezamos por una avería en una fuente de alimentación de uno de los servidores. Una pequeña minucia, pues los dos servidores siguen en marcha y, por supuesto, nuestro monitorizador del SLA ni se inmuta. Se avería otra fuente del otro servidor, se avería una enfriadora… el monitorizador del SLA sigue diciendo que todo está ok, pero la cosa cada vez pinta peor. Con los sistemas de monitorización binarios saltarán las alarmas de las averías, pero sigo sin saber lo cerca que estoy del desastre.

Al final, sólo queda uno de cada cosa: sólo queda en marcha un servidor con una única fuente de alimentación que se comunica con el mundo a través de un único switch, etc, etc. Es decir, una incidencia más y desastre seguro. Hombre, Antonio, has roto muchas cosas a la vez… si, pues rompo sólo dos: rompo los dos switches y hala, se acabó. Se paró el servicio.

Pero si utilizamos un sistema de control con lógica difusa, podemos parametrizar los valores que asignamos a estos componentes para controlar el grado de pertenencia al conjunto de los disponibles. Esto hay que hacerlo en dos formas: controlando la distancia en número de eventos que estamos del desastre y asignando probablilidades a los eventos. En el caso que hemos mencionado, la distancia mínima al desastre es dos: como hemos dicho antes, basta que fallen los dos switches. Si falla un switch no pasa nada si también falla un servidor, pero es obvio que si ha fallado un switch y un servidor es más probable el fallo total que si sólo ha fallado uno (o switch o servidor).

Esto hay que hacerlo bien, controlando todos los elementos que intervienen en cada servicio, comenzando por el cuadro eléctrico y terminando en el último componente de software. Y si con sólo un servicio y la pila de componentes que han intervenido os parece un lío, imaginad en un datacenter grande con cientos o miles de servidores y decenas de miles de servicios.

Supongamos que parametrizo mi disponibilidad difusa entre 1 y 2, en el que 2 significa disponible, riesgo mínimo y 2 significa 1, riesgo extremo. Sé que el teléfono no va a echar humo hasta que la disponibilidad baje de 1, pero seguro que mi comportamiento no va a ser igual si veo en el monitor un 1,001 que si veo un 1,999.

Análogamente, Podemos controlar los incumplimientos con lógica difusa. No es lo mismo que dos de cada diez peticiones se respondan con un tiempo de latencia un poquitín superior al especificado a que el servicio no responda. Incluso cuando nos van a dar collejas es necesario tener las herramientas pera intentar minimizar el número y fuerza de las mismas.

Si os fijáis, esto es una ampliación de los conceptos utilizados en en Thermal Resilience a todos los componentes y servicios del datacenter. Como lo estamos midiendo en positivo, estamos hablando de disponiblidad, pero no deja de ser una forma de medir en tiempo real el riesgo asociado a los servicios: el inverso de la disponibilidad es el riesgo tal como lo trata la ISO 27001.

Cualquier servicio es crítico una vez transgredido el acuerdo de nivel de servicio, así que a cualquier CTO le encantaría saber si las collejas están lejos o cerca, y esto, en el fondo, es un mero problema de probabilidades. Eso sí, un CTO tiene que ser consciente de que  los sucesos improbables también ocurren. Tienes dos ases en la mano, y en la mesa ves un as, dos cuatros, un nueve y un tres. Te ves feliz con tu trío pensando que te has ganado un dinero fácil cuando resulta que el que tenía cara de pardillo tenía otros dos cuatros en la mano, enseña su póker y te deja con cara de memo.

Si, la Ley de Murphy es inexorable. Por eso, cuánto más lo tengamos todo bajo control, mejor. Por eso la disponibilidad es mayor cuando se está sentado confortablemente en el salón que cuando se está como el de la imagen. Así que no lo dudéis, implantad un sistema de gestión de disponibilidad/riesgo así. Si no sabéis como, consultadme!

 

Conceptos básicos de disponibilidad (II)

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

 

 

 

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.