Modelado y gestión de un Centro de Datos

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Trabajo Fin de Máster Máster en Ingeniería Electrónica, Robótica y Automática Modelado y gestión de un Centro de Datos Autor: José Ignacio Murillo Álvarez Tutor: Daniel Rodríguez Ramírez Dpto. Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 Trabajo Fin de Máster Máster en Ingeniería Electrónica, Robótica y Automática Modelado y gestión de un Centro de Datos Autor: José Ignacio Murillo Álvarez Tutor: Daniel Rodríguez Ramírez Profesor Titular Dpto. Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 Trabajo Fin de Máster: Modelado y gestión de un Centro de Datos Autor: José Ignacio Murillo Álvarez Tutor: Daniel Rodríguez Ramírez El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores: Presidente: Vocal/es: Secretario: acuerdan otorgarle la calificación de: El Secretario del Tribunal Fecha: Agradecimientos A gradecer siempre es una forma de compartir un poco de tu trabajo con los que te han dado las herramientas necesarias para llevarlo a cabo. En primer lugar, este trabajo no hubiera sido posible sin la guía y los consejos del tutor, Daniel. Luego, no hubiera podido aplicar todos mis conocimientos sin todos los profesores que han aportado su expertise a lo largo del Grado y del Máster, "diseñando" de esta forma excelentes profesionales y académicos. Por último, en la parte más personal, agradecer a toda mi familia por seguir apoyándome en esta ¿última? etapa de estudios y a Rocío por aguantarme en los momentos más complicados. José Ignacio Murillo Álvarez Sevilla, 2023 I Resumen E n un mundo impulsado por el auge de las nuevas tecnologías, la construcción de infraestructuras para alojar y gestionar los recursos esenciales que sustentan la industria y la vida cotidiana se ha convertido en una necesidad apremiante. Los centros de datos, estructuras costosas pero cruciales, desempeñan un papel fundamental al proporcionar los servicios necesarios en esta era digital. La gestión eficiente de estos centros de datos se vuelve esencial para garantizar el rendimiento deseado y, al mismo tiempo, lograr una alta eficiencia que ahorre costos y reduzca la huella ambiental. Este trabajo se centra en la creación de un modelo de centro de datos genérico, que permite caracterizar y simular su comportamiento. Además, se desarrolla un controlador basado en control predictivo por modelo, utilizando un algoritmo genético para resolver la función de coste. El objetivo principal es abordar las dos principales fuentes de consumo de energía en los centros de datos: el número de servidores activos y la gestión de la refrigeración necesaria para mantener una temperatura segura en los equipos. Finalmente, se llevan a cabo numerosas simulaciones con el propósito de verificar la eficacia del controlador en diversas condiciones operativas. Este enfoque promete optimizar la gestión de centros de datos, contribuyendo así a un uso más eficiente de recursos y una reducción de costos en un mundo cada vez más digitalizado. III XÍndice 4.1 Simulaciones controlador binaro (1, 2, 3). Tareas constantes. 22 4.1.1 Simulación 1 (no reseeding, NC = 1) 22 4.1.2 Simulación 2 (no reseeding, NC = 3) 25 4.1.3 Simulación 3 (reseeding, NC = 3) 28 4.2 Simulaciones controlador entero (4, 5, 6). Tareas constantes. 30 4.2.1 Simulación 4 (no reseeding, NC = 1) 30 4.2.2 Simulación 5 (no reseeding, NC = 5) 35 4.2.3 Simulación 6 (reseeding, NC = 5) 38 4.3 Simulaciones controlador entero con escenarios (7, 8, 9). Tareas constantes. 41 4.3.1 Simulación 7 (no reseeding, NC = 1) 41 4.3.2 Simulación 8 (no reseeding, NC = 5) 44 4.3.3 Simulación 9 (reseeding, NC = 5) 47 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 50 4.4.1 Simulación 10 (no reseeding, NC = 1) 50 4.4.2 Simulación 11 (no reseeding, NC = 5) 53 4.4.3 Simulación 12 (reseeding, NC = 5) 56 4.5 Simulaciones controlador entero (13, 14, 15). Tareas no constantes. 59 4.5.1 Simulación 13 (no reseeding, NC = 1) 59 4.5.2 Simulación 14 (no reseeding, NC = 5) 62 4.5.3 Simulación 15 (reseeding, NC = 5) 65 4.6 Simulaciones controlador entero con escenarios (16, 17, 18). Tareas no constantes. 68 4.6.1 Simulación 16 (no reseeding, NC = 1) 68 4.6.2 Simulación 17 (no reseeding, NC = 5) 71 4.6.3 Simulación 18 (reseeding, NC = 5) 74 4.7 Simulaciones estrategia baseline 77 4.7.1 Simulación estrategia baseline. Tareas constantes 77 4.7.2 Simulación estrategia baseline. Tareas no constantes 78 5 Resultados 83 6 Conclusiones 87 Apéndice A Modelo Centro de Datos 89 A.1 data_center.py 89 A.2 server.py 91 A.3 task.py 92 A.4 probability_functions.py 94 A.5 dc_utils.py 95 Apéndice B Control y simulaciones Centro de Datos 97 B.1 main_simulation.py 97 B.2 params.py 106 B.3 problem_datacenter_binary.py 106 B.4 problem_datacenter_integer.py 111 B.5 get_mean_data.py 116 B.6 batch_simulation.sh 118 Índice de Figuras 119 Índice de Tablas 123 Bibliografía 125 1 Introducción E n la actualidad, el rápido crecimiento de las tecnologías de la información y la comunicación ha tenido como consecuencia la proliferación de instalaciones formadas por un número elevado de servidores dedicados a calcular y almacenar grandes cantidades de datos. Estas instalaciones, que llamaremos de ahora en adelante Centros de Datos, pueden estar destinadas a un elevado número de posibles objetivos, como puede ser la computación interactiva (navegar por páginas web) o transacciones en tiempo real, como en la industria bancaria o en el minado de criptomonedas [1], [2]. Los Centros de Datos, al tratarse de grandes infraestructuras informáticas, tienen un enorme gasto energético. Esto ha hecho que la eficiencia energética de estos enormes equipos tenga un gran impacto económico, ecológico y de rendimiento. Para hacernos una idea, un Centro de Datos estándar puede consumir la energía equivalente a 25000 hogares [ 3 ]. Además, es realmente importante ser eficiente en su uso, ya que, por ejemplo, cuando los equipos están inactivos (idle), también están consumiendo energía sin realmente aportar rendimiento al Centro de Datos. Puede ayudar a mejorar el rendimiento la predicción de carga de trabajo que los equipos van a tener en un intervalo de tiempo, analizando patrones en la demanda. Conocer de forma precisa los equipos que necesitas tener encendidos en cada instante puede tener un impacto gigantesco en la eficiencia y en los costes operacionales de la infraestructura. En [ 4 ], se muestran técnicas para predecir esta capacidad necesaria, permitiendo una reducción del 35% en el procesamiento. Estas cifras pueden tener un impacto vital en el ahorro energético global en un futuro próximo. El mayor gasto energético en un Centro de Datos es el del enfriamiento de los equipos, siendo de hasta un 50% entre las tipologías de los consumos (ver Figura 1.1). Esto provoca que el control preciso de la energía y temperaturas necesarias para mantener la temperatura de los servidores bajo niveles de seguridad sea uno de los aspectos más importantes a la hora del ahorro energético. 1.1 Objetivos Los objetivos del trabajo se pueden dividir en dos grandes bloques: En primer lugar, la creación de un modelo válido para representar el funcionamiento de un Centro de Datos, de forma que podamos trabajar con él y hacer simulaciones válidas. En segundo lugar, el control del correcto funcionamiento según los parámetros deseados por el usuario, minimizando el coste energético, es decir, utilizando el número óptimo de servidores que nos permitan operar según las restricciones del rendimiento esperado, y optimizando el gasto en enfriamiento. 1.2 Metodología La metodología de este proyecto estará fuertemente vinculada al trabajo descrito en [ 6 ], donde se desarrolla un modelo válido y se describe un control del Centro de Datos mediante Control Predictivo. Este tipo de controlador busca minimizar una función de coste, usando un modelo del sistema para predecir la salida del proceso en el futuro, calculando así una secuencia de control óptima. En el trabajo mencionado, se busca minimizar la función de coste usando Optimización basada en Partículas [ 7 ], mientras que en este buscaremos una forma diferente de resolver el problema de optimización utilizando Algoritmos Genéticos (GA), concretamente un algoritmo diseñado para trabajar con variables enteras y reales [8]. 1 2Capítulo 1. Introducción Figura 1.1 Energía consumida en un Centro de Datos típico [5]. Para ello, usaremos como herramienta de desarrollo el lenguaje de programación Python [ 9 ]. Este lenguaje destaca por su facilidad de uso, ya que tiene una sintaxis clara y legible, además de ser interpretado, lo que evita la necesidad de compilación. Además, tiene una amplia comunidad activa y un gran número de librerías y módulos que podemos usar de forma libre para nuestros desarrollos. 1.3 Sumario Primero, en el Capítulo 2, definiremos con detalle el modelo del Centro de Datos con el que se va a trabajar en el resto del proyecto, describiendo los comportamientos de las tareas, los servidores y la evolución térmica de los sistemas. A continuación, en el Capítulo 3, introduciremos las técnicas de control y gestión que vamos a utilizar para garantizar el funcionamiento deseado del Centro de Datos, empezando por la descripción de los algoritmos y terminando por su implementación en el modelo desarrollado en el Capítulo 2. Luego, en el Capítulo 4, detallaremos cómo se van a llevar a cabo las distintas simulaciones, y mostraremos las gráficas y datos más importante de cada una de ellas. En relación a los datos obtenidos en el Capítulo 4, mostraremos los aspectos más importantes, comparaciones y comentarios pormenorizados en el Capítulo 5. Finalmente, en el Capítulo 6, terminaremos con las conclusiones y los posibles trabajos futuros que derivan de este desarrollo. 2 Modelado del Centro de Datos L os Centros de Datos se componen generalmente de unidades aisladas térmicamente donde se colocan los servidores siguiendo una estructura CA (Cold Aisle) [ 6 ]. El aire frío utilizado para hacer descender la temperatura es generado por una unidad de aire acondicionado CRAC (Computer Room Air Conditioning) especialmente diseñada para estos espacios. La unidad CRAC es la encargada de generar aire frío para mantener la temperatura de los servidores controlada, lo cual es importante para que esta no sobrepase niveles que pueden ser perjudiciales para el funcionamiento de los equipos. Además, el control eficiente de la temperatura del aire frío es beneficioso tanto para los costes operacionales como para el alto impacto ambiental que producen estas instalaciones alrededor del mundo [10]. Desarrollamos el modelo del Centro de Datos como un modelo discretizado, con un paso de integración ts y una unidad discreta de tiempo k. 2.1 Modelo de las tareas Presentamos un modelo basado en una cola compartida por múltiples servidores [11]. Figura 2.1 Modelo basado en única cola con múltiples servidores.. Esta cola se llenará con las tareas que vayan llegando. Definimos el ratio de solicitud como L(k) , que marca el número de tareas que llegarán en cada instante k . Modelamos este parámetro como una variable aleatoria que sigue una distribución de Poisson de media 1/kay función de probabilidad: 3 4Capítulo 2. Modelado del Centro de Datos g(n) = 1 n!1 kan e−1 ka(2.1) Cada una de estas tareas tendrá una carga de trabajo Wk . Esta variable aleatoria seguirá una distribución exponencial con media 1/µ. W(k) = µe−kµ(2.2) Los parámetros ka y µ también definen el número mínimo de servidores (M) para el cual la cola no crecerá de forma infinita: M≥1 kaµ(2.3) 2.2 Modelo de los servidores El estado de un servidor quedará caracterizado por el número de tareas ejecutándose en el Centro de Datos ( α ), el número de tareas en la cola ( β ), la temperatura del aire frío del CRAC ( Tc ), la temperatura del servidor (Ti) y el instante de tiempo en el que fue encendido (ki): xi(k) = [α(k),β(k),Tc(k),Ti(k),ki](2.4) Teniendo en cuenta todos los estados xi(k), obtenemos el estado del Centro de Datos. xT(k) = [α(k),β(k),Tc(k),T1(k),...,TM(k),k1,...,kM](2.5) Los servidores podrán cambiar entre cuatro posibles estados: 1. Off - El servidor no consume potencia (pi=0). 2. Booting - Transición de Off a Working o Idle. Toma un tiempo de encendido ( kon ) realizar esta transición. La potencia consumida es igual que en Idle (pi=a2). 3. Working - El servidor está encendido y procesando alguna tarea. Consume una potencia constante (pi=a1+a2). 4. Idle - El servidor está encendido pero no procesa tarea. Consume menos potencia que en Working (pi=a2). Figura 2.2 Estados y transiciones en un servidor.. 2.3 Modelo térmico del Centro de Datos 5 Asumimos que una tarea puede ser repartida entre múltiples servidores, pero un servidor no puede trabajar en varias tareas. Esto complica el modelo, ya que no trabajará como una cola M/M/c , pero mejorá el rendimiento del Centro de Datos. Siempre que el número de nuevas tareas Lk sea mayor o igual que el número de servidores disponibles, se asignarán las tareas individualmente. Cuando el número de nuevas tareas es menor que el número de servidores disponibles, la tarea con mayor carga de trabajo se dividirá entre los servidores sobrantes tras repartir el resto de tareas. 2.3 Modelo térmico del Centro de Datos El balance térmico de cada uno de los servidores tendrá la siguiente expresión [6]: Kt dTi(t) dt =cpqa(t)(Tc(t)−Ti(t))+ pi(t)) (2.6) Donde: •Tc= Temperatura aire frío CRAC. •qa= Flujo aire frío CRAC. •Ti= Temperatura del servidor i. •pi= Potencia consumida por el servidor i. •Kt= Capacidad calorífica del servidor. •qp= Capacidad calorífica del aire. Discretizando esta expresión para usarla en nuestro modelo, obtenemos: Ti(k+1) = Ti(k)+ ts Ktcpqa(k)(Tc(k)−Ti(k))+ pi(k)(2.7) Para garantizar la fiabilidad de los servidores, hay que mantener la temperatura bajo unos niveles de seguridad determinados. La restricción es: Ti≤80◦C∀i∈M(2.8) La variable Tc es regulada por el set point Tr . Este expresa la temperatura deseada del aire frío del CRAC. Tc seguirá a Tr con una dinámica en bucle cerrado de primer orden, con ganancia unidad y una constante de tiempo τ: τdTc(t) dt =Tr(t)−Tc(t)(2.9) En tiempo discreto: Tc(k+1) = Tc(k)+ ts τ(Tr(k)−Tc(k)) (2.10) Los valores de Tr(t)deben estar dentro del siguiente intevalo durante todos los instantes de tiempo: 15◦C≤Tr(t)≤25◦C (2.11) En función de Tc , el coeficiente de rendimiento (CoP) del CRAC cambiará. El CoP representa cómo de costoso es enfriar el aire de la habitación cuando nos encontramos en una temperatura determinada. A temperaturas más bajas, necesitaremos más potencia para seguir enfriando. 6Capítulo 2. Modelado del Centro de Datos CoP(Tc(k)) = 0.0068Tc(k)2+0.0008Tc(k)+0.458 [12](2.12) Siendo ∑M i=1pi(k,xi,ui)la potencia de los servidores, la potencia consumida por el CRAC será: ∑M i=1pi(k,xi,ui) CoP(Tc(k)) (2.13) Finalmente, la potencia total consumida por el Centro de Datos será: M ∑ i=11+1 CoP(Tc(k))pi(k,xi,ui)(2.14) 2.4 Modelo de la Calidad del Servicio (QoS) El QoS (Quality of Service) se define como el tiempo requerido para terminar una tarea desde su entrada en el Centro de Datos. Es decir, incluye el tiempo desde que espera en la cola hasta que su procesamiento termina. Este dato es de vital importancia en la gestión y control de los Centros de Datos, ya que debemos mantenernos por debajo de un valor acordado con el cliente. Si las tareas pudieran ser asignadas sólo a un servidor, como en una cola de tipo M/M/c , el QoS medio en cada instante ksería de: QoS(k) = 1 m(k) W(k)−L(k)(2.15) Donde, en la práctica, W(k)yL(k)serían estimaciones de estas variables estadísticas. En este modelo, como puede haber tareas que sean compartidas por varios servidores, este valor solo puede ser menor o igual. QoS(k)≤1 m(k) W(k)−L(k)(2.16) A partir de esta expresión, podemos obtener la restricción de rendimiento que nos indica el QoS medio deseado: mD(k) = W(k)1 D+L(k)(2.17) Donde D es el valor que no queremos que el QoS medio supere, y mD(K) la restricción en el número de servidores encendidos en el instante kque tendremos que satisfacer para garantizar ese rendimiento. 2.5 Implementación Hemos llevado a cabo la implementación del modelo usando el lenguaje de programación Python, el cual nos ha permitido seguir una estructura orientada a objetos. La programación orientada a objetos (POO) es un paradigma de programación basado en el concepto de objetos, que pueden contener datos y código: datos en forma de campos (a menudo conocidos como atributos o propiedades), y código en forma de procedimientos (a menudo conocidos como métodos) [13]. Este tipo de programación tiene algunas ventajas que nos han servido en este desarrollo, como pueden ser la modularidad, mejor mantenimiento del código, diseño más entendible por el usuario o reusabilidad [14]. 2.5 Implementación 7 El código y su estructura se puede revisar en los anexos. En la Figura 2.3 podemos ver un esquema de la estructura de las clases de nuestro proyecto Server yTask. Figura 2.3 Ejemplo clases Server yTask. 3 Control del Centro de Datos 3.1 Definición del problema de control 3.1.1 Control Predictivo por Modelo (MPC) El Control Predictivo por Modelo (MPC) cuenta con numerosas ventajas respecto a otras técnicas más básicas usadas en la industria (como el controlador PID), especialmente cuando tenemos un problema con restricciones y/o con múltiples variables de control. Esta técnica hace uso de un modelo del sistema para predecir el efecto que tendrá una secuencia de acciones de control en el futuro, obteniendo esta secuencia mediante la minimización de una función de coste. Se puede resumir la naturaleza de este tipo de controlador en tres ideas [15]: 1. Uso explícito de un modelo para predecir la salida del proceso a lo largo de un horizonte futuro de tiempo. 2. Cálculo de una secuencia de control que optimiza un índice de rendimiento, definido por la función de coste. 3. "Receding horizon strategy", lo que quiere decir que en cada instante de tiempo el horizonte se mueve hacia el futuro, aplicando únicamente la primera señal de control de la secuencia calculada en cada paso. Si nos fijamos en la Figura 3.1, vemos más claro que: 1. El modelo del proceso predice en cada instante k la salida futura para k,k+1,...,k+Np (Predicted optimal trayectory), donde Np es conocido como el Horizonte de Predicción. Esta predicción dependerá de los valores actuales del proceso, así como de la secuencia de control futura que debemos calcular. 2. La secuencia de control futura (Optimal control sequence) se calcula para optimizar la función de coste. Normalmente, el esfuerzo de control es utilizado en ese criterio. Esta secuencia futura se calcula para k,k+1,...,k+Nc , siendo Nc el Horizonte de Control. Durante el tiempo Np−Nc , se mantiene constante la última acción de control de la secuencia. 3. Solo la primera señal de control de la secuencia se aplica en el instante k . En el siguiente instante de control, se mide la salida del proceso y se vuelve al paso 1. En [ 6 ], se desarrolla un algoritmo basado en Control Predictivo por Modelo para gestionar el Centro de Datos. En este caso, el modelo del proceso es el mismo desarrollado en el Capítulo 2. La función de coste, así como las restricciones, serán las mismas que aplicaremos en este trabajo. V(l0,x,u,Tr) = Np ∑ j=0 M ∑ i=0 1+1 CoP(Tc(lj))!pi(lj,xi,ui)+ λu Nc ∑ i=0|∆u(lj)|+λTr Nc ∑ i=0|∆Tr(lj)|(3.1) Donde lj son los instantes en los que se aplica el controlador, que vendrá determinado por el intervalo de muestreo km. Es decir, lj=k+jkm. 9 16 Capítulo 3. Control del Centro de Datos Siendo x(ln|k) la acción de control óptima encontrada en el instante k para el instante de control n . Como, en el instante k , la acción de control óptima para el instante 1 es x(l1|k) , es sencillo pensar en que esa puede ser un buen candidato para la acción de control, que acabará convirtiéndose en óptima tras el siguiente paso por el algoritmo en k+1 . Esto se aplica igualmente para el resto de instantes de control hasta Nc−1 . Entonces, nos faltaría una acción de control para completar el tamaño Nc del individuo, por lo que la última acción de control se repetiría. El individuo desplazado quedaría de la siguiente forma: xl1=     x(l1|k) . . . xlNc−1|k xlNc−1|k     (3.22) Estas partículas se añadirían a la población inicial formando un porcentaje de esta, determinado por el usuario. Cabe destacar que las partículas se elegirán para el desplazamiento según su puntuación. Aportar una serie de soluciones sub-óptimas para la población y generar otros individuos de forma aleatoria nos puede ayudar a cubrir bastante mejor el espectro de posibles soluciones, disminuyendo previsiblemente las iteraciones necesarias para encontrar el óptimo de la función de coste. 3.3.2 Estimación de WkmyLkm Para la estimación de Wkm y Lkm , es decir, la carga del trabajo y el ratio de solicitud en cada instante de control km , vamos a optar por guardar en memoria los últimos n valores de cada variable, para luego hacer la media y calcular mD(km)como se especifica en 3.25. d Wkm=∑k−1 j=km−nWk(j) n(3.23) c Lkm=∑k−1 j=km−nLk(j) n(3.24) mD(km) = d Wkm1 D+c Lkm(3.25) 3.3.3 Optimización basada en escenarios En [ 6 ], se opta por una optimización en la que los valores estimados de Lkm y Wkm no son estimados con un solo valor en cada iteración km , si no que se opta por, dando por conocida cual es la distribución estadística de estas variables, crear una serie de posibles valores que estas podrían tomar en el futuro según esta distribución. Esta lista de posibles valores recibe el nombre de escenarios. Entonces, se calcula el coste y se comprueban las restricciones de cada individuo para cada uno de los escenarios en cada iteración, lo que aumenta considerablemente el coste computacional. Para calcular el coste óptimo, se toma en cuenta aquel individuo cuya suma de costes en cada escenario es menor, es decir, la función de coste pasaría a tener esta forma: V(l0,x,u,Tr) = S ∑ s=0 Np ∑ j=0 M ∑ i=0 1+1 CoP(Tc(lj))!pi(lj,xi,ui)+ λu Nc ∑ i=0|∆u(lj)|+λTr Nc ∑ i=0|∆Tr(lj)|!(3.26) Siendo sel índice de escenario y Sel número total de escenarios. En el caso en que el escenario es unitario (la estimación de Lkm y Wkm es un único valor) es simplemente un caso concreto del algoritmo de optimización completo, que seguirá los pasos que podemos ver en el Algoritmo 1. La inclusión del algoritmo basado en escenarios nos permite ser más restrictivos a la hora de calcular el número mínimo de servidores necesarios para mantener el rendimiento en el instante km , lo cual debe repercutir en un funcionamiento superior en estos términos, y a su vez en un coste mayor. 3.3 Implementación MI-LXPM en el caso de uso 17 Algorithm 1 Optimización basada en escenarios con MI-LXPM Datos: PS (tamaño de la población), Np , Nc , V(.) (función de coste), r (porcentaje de reseeding), S (número de escenarios), nmean (número de valores anteriores para realizar la estimación de Wk y Lk ), D ( QoS deseado), iter (número de iteraciones del algoritmo MI-LXPM). Resultados: Mejor individuo x∗. 1: Reseeding. Obtener los mejores rX individuos de la población anterior y añadir (1−r)X nuevos individuos generados aleatoriamente; 2: Estimación de WkyLkusando la ecuación 3.23. 3: if S=1then 4: escenario = (d Wkm,c Lkm); 5: else 6: Calculamos Sescenarios aleatoriamente usando la expresión 2.2 y 2.1; 7: end if 8: for i=1,...,iter do 9: Aplicar operador de selección por torneo (3.2.3); 10: Aplicar operador de cruce de Laplace (3.2.1); 11: Aplicar operador de mutación (3.2.2); 12: Aplicar operador de truncado (3.2.4); 13: for cada escenario do 14: Predecir la salida del sistema para cada individuo a lo largo de Np; 15: Calcular el coste para cada individuo; 16: end for 17: Gestionar restricciones (3.2.5); 18: Sumar el coste de cada escenario para cada individuo; 19: end for 20: Elegir el individuo con mejor coste total →x∗; 4 Simulaciones U na vez hemos definido tanto el modelo del Centro de Datos como el controlador que vamos a usar en este trabajo, pasamos en este apartado a realizar las simulaciones pertinentes para comprobar el rendimiento de los diferentes algoritmos que hemos integrado. Además, compararemos estos resultados con los de una estrategia simple de control. En esta estrategia, se tratarán por separado el control de los servidores y el control de la temperatura del CRAC. Para el encendido de los equipos, la estrategia será la mas simple posible [ 23 ], encender los M servidores, mientras que para establecer la tempreatura de referencia del CRAC se calculará la temperatura requerida para mantener un servidor a la temperatura de restricción (en este caso, 80◦C ) mientras consume la mayor potencia posible (a1+a2): Tr(k) = Tr=80◦C−a1+a2 cpqa =20◦C(4.1) Tabla 4.1 Lista de simulaciones. Tareas Escenarios Tipo Reseeding NC NP Sim 1 Cte 1 Binario No 1 10 Sim 2 Cte 1 Binario No 3 10 Sim 3 Cte 1 Binario Sí 3 10 Sim 4 Cte 1 Entero No 1 10 Sim 5 Cte 1 Entero No 5 10 Sim 6 Cte 1 Entero Sí 5 10 Sim 7 Cte 10 Entero No 1 10 Sim 8 Cte 10 Entero No 5 10 Sim 9 Cte 10 Entero Sí 5 10 Sim 10 Cambia 1 Binario No 1 10 Sim 11 Cambia 1 Binario No 3 10 Sim 12 Cambia 1 Binario Sí 3 10 Sim 13 Cambia 1 Entero No 1 10 Sim 14 Cambia 1 Entero No 5 10 Sim 15 Cambia 1 Entero Sí 5 10 Sim 16 Cambia 10 Entero No 1 10 Sim 17 Cambia 10 Entero No 5 10 Sim 18 Cambia 10 Entero Sí 5 10 19 20 Capítulo 4. Simulaciones Hemos creado una tabla (ver Tabla 4.1) donde definimos los parámetros que va a utilizar cada una de las pruebas de simulación que mostraremos en el capítulo. Dentro de esta tabla, tenemos varias columnas que se irán modificando para generar diferentes resultados y poder realizar comparaciones: 1. Tareas. Este parámetro determinará si las tareas llegan con una media constante o si estos parámetros estadísticos cambian a lo largo de la simulación. En el caso que sea Cte (constante), las tareas llegarán con una tasa de solicitud, siguiendo la distribución estadística vista en la expresión 2.1, una distribución de Poisson de media 1/ka . Si el caso es Cambia , la media de la tasa de solicitud seguirá una distribución normal: µ(t) = k·1 σ√2πexp−(t−tmid )2 2σ2(4.2) Donde tmid =tsim 2,k=5 ka yσ=250 ka . En todas las simulaciones, ka=1. 2. Escenarios. Determina el número de escenarios que se contemplan en el problema de optimización. 3. Tipo. Problema binario o entero. 4. Reseeding. Se utilizan individuos de la población anterior. 5. NC y NP. Valores del horizonte de control y horizonte de predicción. En las simulaciones, habrá una serie de valores que se mantendrán constantes cuando no se especifique lo contrario: •r=0.7(porcentaje de reseeding). •nmean =50 (número de valores anteriores para realizar la estimación de WkyLk). •D=10 (QoS deseado). El tamaño de población PS variará entre los problemas binario y entero, dependiendo además del Nc , ya que este parámetro aumenta el tamaño del individuo. Entonces PSbin Nc=1=500 , PSbin Nc=3=1000 , PSint Nc=1=100 y PSint Nc=5=1000 . En general, el problema binario cuenta con una cantidad de posibles soluciones mucho mayor que el problema entero. Tras hacer pruebas con los valores del algoritmo MI-LXPM, nos damos cuenta que es necesario tunear sus hiperparámetros para conseguir una evolución correcta de sus individuos. Para las simulaciones con menos posibles valores ( Nc=1 , Simulación 1, 4, 7, 10, 13, 16) era menos importante este tuneo. Los valores para estas simulaciones han sido: Parámetros MI-LPXM iniciales •max iterations = 50 •Laplace Crossover : a = 0, br = 0.15, bi = 0.05, probabilidad cruce = 0.8 •Power mutation : pr = 10, pi = 10, probabilidad mutación = 0.5 •D=10 (QoS deseado). Para el resto de simulaciones, estos valores arrojaban resultados en los que apenas se producía evolución en la población, lo que conlleva soluciones muy lejanas al óptimo. A base de prueba y error, se obtienen unos parámetros aceptables para esos casos, diferenciando entre el controlador binario y el entero, ya que el valor que pueden tomar las variables es diferente en cada caso (entre 0 y 1 o entre 0 y 25). Parámetros controlador binario •max iterations = 100 •Laplace Crossover : a = 0, br = 0.15, bi = 0.2, probabilidad cruce = 0.8 •Power mutation : pr = 1, pi = 0.05, probabilidad mutación = 0.8 •D=10 (QoS deseado). 21 Parámetros controlador entero •max iterations = 100 •Laplace Crossover : a = 0, br = 0.15, bi = 0.5, probabilidad cruce = 0.8 •Power mutation : pr = 1, pi = 1, probabilidad mutación = 0.8 •D=10 (QoS deseado). Los valores de las variables necesarias para reproducir el modelo tendrán los siguientes valores: Valores modelo •M=25 (número de servidores). •ts=1s(paso de simulación). •km=100s(intervalo del controlador). •QoS =10 (Quality of Service). •τ=180 (Constante de tiempo CRAC). •Kt=160(J/k)(Capacidad térmica del servidor). •cpqa=5(W/K)(Capacidad térmica del aire por el flujo). •a1=180W,a2=120W(Potencia consumida por el servidor). •lambdau=200,lambdaTr=100 (Ponderaciones para penalizar los cambios en la acción de control). •Mean Workload = 3 (valor medio de la carga de trabajo de las tareas) En los casos de un solo escenario, con controlador binario, se realizarán un total de 20 simulaciones por caso, mientras que para las simulaciones con controlador entero, se realizarán 50 simulaciones para NC=1 y 20 simulaciones para NC=5. En los casos de varios escenarios, en aquellas simulaciones en las que el tiempo de computación de la iteración del controlador era superior a 300 segundos (Simulación 7, 8, 17, 18), se han realizado 10 iteraciones. En la simulación del controlador base, se han realizado 50 simulaciones. Las gráficas y datos que veremos en cada simulación son los siguientes: • Longitud media de la cola, media de servidores encendidos + media servidores minimos estimados, media potencia total consumida (W), media de servidores inactivos (idle). • Coste total del controlador, media de esfuerzo de control para encender servidores, media de esfuerzo de control para cambiar la temperatura del CRAC. •Evolución de la temperatura de los servidores (K) (1 sola simulación). •Media evolución del coste en las iteraciones del MI-LXPM (1 sola simulación). • Tabla: QoS medio, porcentaje de tareas que superan el tiempo de servicio, media potencia (W), media coste controlador, tiempo de computación en cada instante de control. 22 Capítulo 4. Simulaciones 4.1 Simulaciones controlador binaro (1, 2, 3). Tareas constantes. 4.1.1 Simulación 1 (no reseeding, NC = 1) Figura 4.1 Simulación 1. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 4.1 Simulaciones controlador binaro (1, 2, 3). Tareas constantes. 23 Figura 4.2 Simulación 1. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.3 Simulación 1. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 24 Capítulo 4. Simulaciones Figura 4.4 Simulación 1. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.2 Simulación 1. QoS y potencia media. QoS medio 6.57 Porcentaje de tareas que superan el tiempo de servicio 20.44% Potencia consumida media 851.60 W Tiempo de computación 8.46 s El resultado de servidores encendidos es idéntico al de los mínimos servidores estimados para cumplir la restricción de QoS , lo que indica que la optimización converge a ese valor mínimo correctamente. El QoS medio está por debajo del valor deseado. El esfuerzo de control para cambiar la temperatura de referencia del CRAC es nulo en prácticamente toda la simulación, mientras que el del switch de servidores si que se mantiene relativamente alto para ser un escenario con tareas constantes. Esto puede ser una consecuencia de la cantidad de posiblidades que hay de mantener estas restricciones con el controlador binario manteniendo un coste bajo, ya que son 25 variables. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es notable, con un valor del 35.29%. 4.1 Simulaciones controlador binaro (1, 2, 3). Tareas constantes. 25 4.1.2 Simulación 2 (no reseeding, NC = 3) Figura 4.5 Simulación 2. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 32 Capítulo 4. Simulaciones Figura 4.14 Simulación 4. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.15 Simulación 4. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.2 Simulaciones controlador entero (4, 5, 6). Tareas constantes. 33 Figura 4.16 Simulación 4. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. 34 Capítulo 4. Simulaciones Tabla 4.5 Simulación 4. QoS y potencia media. QoS medio 5.81 Porcentaje de tareas que superan el tiempo de servicio 16.38% Potencia consumida media 844.24 W Tiempo de computación 3.13 s El resultado de servidores encendidos es idéntico al de los mínimos servidores estimados para cumplir la restricción de QoS , lo que indica que la optimización converge a ese valor mínimo correctamente. El QoS medio está por debajo del valor deseado. El esfuerzo de control para cambiar la temperatura de referencia del CRAC es nulo en prácticamente toda la simulación, así como el esfuerzo del switch de servidores. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es muy pequeña, con un valor del 3.2%. La explicación es que en esta simulación, el rango de valores que puede tomar la solución es bajo (hay 25 posibilidades), por lo que con la generación inicial (100 posibles valores) es fácil dar con una solución casi óptima. 4.2 Simulaciones controlador entero (4, 5, 6). Tareas constantes. 35 4.2.2 Simulación 5 (no reseeding, NC = 5) Figura 4.17 Simulación 5. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 36 Capítulo 4. Simulaciones Figura 4.18 Simulación 5. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.19 Simulación 5. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.2 Simulaciones controlador entero (4, 5, 6). Tareas constantes. 37 Figura 4.20 Simulación 5. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.6 Simulación 5. QoS y potencia media. QoS medio 5.43 Porcentaje de tareas que superan el tiempo de servicio 14.54% Potencia consumida media 855.64 W Tiempo de computación 42.19 s El resultado de servidores encendidos está muy cerca de los mínimos servidores estimados para cumplir la restricción de QoS , lo que indica que la optimización converge a ese valor mínimo correctamente. El QoS medio está por debajo del valor deseado. El esfuerzo de control para cambiar la temperatura de referencia del CRAC varía más en la simulación que en el caso con Nc=1, mientras que el del switch de servidores se mantiene cercano a cero. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es notable, con un valor del 42.61%, mucho mayor que en el caso anterior, lo cual cobra sentido al ser este caso con Nc=5 , aumentando el número de posibles soluciones. 38 Capítulo 4. Simulaciones 4.2.3 Simulación 6 (reseeding, NC = 5) Figura 4.21 Simulación 6. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 4.2 Simulaciones controlador entero (4, 5, 6). Tareas constantes. 39 Figura 4.22 Simulación 6. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.23 Simulación 6. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 40 Capítulo 4. Simulaciones Figura 4.24 Simulación 6. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.7 Simulación 6. QoS y potencia media. QoS medio 5.96 Porcentaje de tareas que superan el tiempo de servicio 15.17% Potencia consumida media 910.74 W Tiempo de computación 40.41 s El resultado de servidores encendidos está muy cerca de los mínimos servidores estimados para cumplir la restricción de QoS , lo que indica que la optimización converge a ese valor mínimo correctamente. El QoS medio está por debajo del valor deseado. Sin embargo, en este caso, el valor está más lejos del óptimo que en el caso sin reseeding, aunque parece que se debe a algunos outliers, mientras que en el resto de la simulación el valor se mantiene idéntico al mínimo. El esfuerzo de control varía específicamente en estos valores fuera del mínimo. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es menor que en el caso sin reseeding, como es de esperar, con un valor del 22.65%. 4.3 Simulaciones controlador entero con escenarios (7, 8, 9). Tareas constantes. 41 4.3 Simulaciones controlador entero con escenarios (7, 8, 9). Tareas constantes. 4.3.1 Simulación 7 (no reseeding, NC = 1) En las simulaciones con escenarios, se representa en la segunda subfigura de la primera figura, la media del mayor valor que se obtiene de mínimos servidores en cada grupo de escenarios. Creemos que este valor es importante, ya que marcará la restricción. Este valor puede estar muy por encima de los mínimos servidores debido a que no se restringe que pueda ser mayor que 25, por lo que este valor pondera en la media, mientras que el máximo número de servidores nunca puede ser mayor que 25. Figura 4.25 Simulación 7. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 48 Capítulo 4. Simulaciones Figura 4.34 Simulación 9. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.35 Simulación 9. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.3 Simulaciones controlador entero con escenarios (7, 8, 9). Tareas constantes. 49 Figura 4.36 Simulación 9. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.10 Simulación 9. QoS y potencia media. QoS medio 2.20 Porcentaje de tareas que superan el tiempo de servicio 1.96% Potencia consumida media 2459.28 W Tiempo de computación 319.74 s El resultado de servidores encendidos está cercano al escenario más conservador. El QoS es mucho más bajo que en las simulaciones sin escenarios. El reseeding parece que ayuda a bajar mínimamente el costo, pero es muy poco. En el caso con escenarios, la mayor variabilidad en las soluciones puede hacer que esta práctica no sea tan útil. El esfuerzo de control es alto en los dos tipos. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es mucho menor que un poco más bajo que en el caso anterior, un 15.55%, lo que apoya la tesis de que en este caso el reseeding tiene un papel menos importante. 50 Capítulo 4. Simulaciones 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 4.4.1 Simulación 10 (no reseeding, NC = 1) Figura 4.37 Simulación 10. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 51 Figura 4.38 Simulación 10. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.39 Simulación 10. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 52 Capítulo 4. Simulaciones Figura 4.40 Simulación 10. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.11 Simulación 10. QoS y potencia media. QoS medio 22.58 Porcentaje de tareas que superan el tiempo de servicio 56.39% Potencia consumida media 1452.32 W Tiempo de computación 8.50 s El resultado de servidores encendidos está cercano al mínimo. En este caso, el QoS está por encima del valor deseado (10), lo cual podemos explicar observando las gráficas. El controlador no consigue adaptarse bien a la demanda con las estimaciones de Wk y Lk , ya que sólo podemos basarnos en datos del pasado, y actualizarnos cada 100 iteraciones. Se puede ver claramente como, cuando la demanda comienza a subir, la cola crece y los servidores en IDLE pasan a ser completamente cero. El esfuerzo de control es casi nulo para la temperatura del CRAC, mientras que para encender y apagar servidores sigue una forma parecida a la de la demanda de las tareas. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 13.63%. 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 53 4.4.2 Simulación 11 (no reseeding, NC = 5) Figura 4.41 Simulación 11. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 54 Capítulo 4. Simulaciones Figura 4.42 Simulación 11. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.43 Simulación 11. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 55 Figura 4.44 Simulación 11. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.12 Simulación 11. QoS y potencia media. QoS medio 13.77 Porcentaje de tareas que superan el tiempo de servicio 40.15% Potencia consumida media 1960.82 W Tiempo de computación 52.88 s El resultado de servidores encendidos es muy parecido al caso con tareas constantes, en la Simulación 2 (4.1.2), por encima del valor mínimo, excepto cuando aumenta la demanda. Esto puede deberse a que hay menos valores posibles que estén cumpliendo restricciones en ese caso. El esfuerzo de control es alto para los dos tipos. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 18.40%. 56 Capítulo 4. Simulaciones 4.4.3 Simulación 12 (reseeding, NC = 5) Figura 4.45 Simulación 12. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 4.4 Simulaciones controlador binario (10, 11, 12). Tareas no constantes. 57 Figura 4.46 Simulación 12. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.47 Simulación 12. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 64 Capítulo 4. Simulaciones Figura 4.56 Simulación 14. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.15 Simulación 14. QoS y potencia media. QoS medio 14.25 Porcentaje de tareas que superan el tiempo de servicio 43.39% Potencia consumida media 1499.09 W Tiempo de computación 41.13 s El resultado de servidores encendidos está cercano al mínimo. Mejor optimización que en el caso binario. El esfuerzo de control es alto para la temperatura, y sigue una forma parecida a la demanda para el switch de los servidores. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 24.03%. 4.5 Simulaciones controlador entero (13, 14, 15). Tareas no constantes. 65 4.5.3 Simulación 15 (reseeding, NC = 5) Figura 4.57 Simulación 15. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 66 Capítulo 4. Simulaciones Figura 4.58 Simulación 15. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.59 Simulación 15. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.5 Simulaciones controlador entero (13, 14, 15). Tareas no constantes. 67 Figura 4.60 Simulación 15. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.16 Simulación 15. QoS y potencia media. QoS medio 13.23 Porcentaje de tareas que superan el tiempo de servicio 31.77% Potencia consumida media 1611.34 W Tiempo de computación 41.23 s El resultado de servidores encendidos es un poco menos óptimo que en la simulación sin reseeding. Pasa algo parecido en el caso de tareas constantes. El esfuerzo de control es alto para la temperatura, y sigue una forma parecida a la demanda para el switch de los servidores. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 24.23%, incluso un poco más alto que en el caso sin reseeding. 68 Capítulo 4. Simulaciones 4.6 Simulaciones controlador entero con escenarios (16, 17, 18). Tareas no constantes. 4.6.1 Simulación 16 (no reseeding, NC = 1) Figura 4.61 Simulación 16. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 4.6 Simulaciones controlador entero con escenarios (16, 17, 18). Tareas no constantes. 69 Figura 4.62 Simulación 16. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.63 Simulación 16. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 70 Capítulo 4. Simulaciones Figura 4.64 Simulación 16. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.17 Simulación 16. QoS y potencia media. QoS medio 3.60 Porcentaje de tareas que superan el tiempo de servicio 8.03% Potencia consumida media 2856.42 W Tiempo de computación 25.71 s El resultado de servidores encendidos está cercano al escenario más conservador. El QoS es mucho más bajo que en las simulaciones sin escenarios. El esfuerzo de control en la temperatura del CRAC no es muy alto, pero sí lo es el del switch de los servidores. Esto también pasa en la simulación análoga pero con caso constante, la Simulación 8 (4.3.2). La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 1.50%, muy baja. 4.6 Simulaciones controlador entero con escenarios (16, 17, 18). Tareas no constantes. 71 4.6.2 Simulación 17 (no reseeding, NC = 5) Figura 4.65 Simulación 17. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle). 72 Capítulo 4. Simulaciones Figura 4.66 Simulación 17. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores. Figura 4.67 Simulación 17. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.6 Simulaciones controlador entero con escenarios (16, 17, 18). Tareas no constantes. 73 Figura 4.68 Simulación 17. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones. Tabla 4.18 Simulación 17. QoS y potencia media. QoS medio 2.89 Porcentaje de tareas que superan el tiempo de servicio 3.27% Potencia consumida media 2922.64 W Tiempo de computación 314.05 s El resultado de servidores encendidos está cercano al escenario más conservador. El QoS es mucho más bajo que en las simulaciones sin escenarios. El esfuerzo de control es alto en los dos tipos. La temperatura de los servidores se mantiene dentro de las restricciones operativas. La evolución en las iteraciones del algoritmo genético es de un 11.36%. 80 Capítulo 4. Simulaciones Figura 4.76 Simulación baseline cambia. Evolución de la temperatura de los 25 servidores durante una de las simulaciones. 4.7 Simulaciones estrategia baseline 81 Tabla 4.21 Simulación baseline cambia. QoS y potencia media. QoS medio 2.47 Porcentaje de tareas que superan el tiempo de servicio 2.02% Potencia consumida media 4828.39 W 5 Resultados T ras realizar todas las simulaciones planificadas, donde hemos tenido en cuenta gran cantidad de parámetros, lo primero que vamos a ilustrar en este apartado es una tabla donde tener de un vistazo una comparación entre todas las casuísticas que hemos estudiado. Añadiremos los valores que hemos comparado en cada una de las tablas de cada simulación, además de otros parámetros que hemos considerado de interés, como la evolución del coste en la optimización tras cada iteración y el coste total del controlador, donde se verá reflejado, además de la potencia consumida por el centro de datos, el esfuerzo de control realizado con los cambios de la temperatura de referencia del CRAC y de los servidores encendidos. Para una mayor claridad y esquematización, dividiremos los datos en cuatro tablas. Compartiremos previo a cada tabla las filas de la Tabla 4.1 correspondientes para facilitar la lectura de los datos. Tabla 5.1 Tabla 1. Tareas constantes, sin escenarios (Simulaciones base, 1, 2, 3, 4, 5, 6). Tareas Escenarios Tipo Reseeding NC NP Sim 1 Cte 1 Binario No 1 10 Sim 2 Cte 1 Binario No 3 10 Sim 3 Cte 1 Binario Sí 3 10 Sim 4 Cte 1 Entero No 1 10 Sim 5 Cte 1 Entero No 5 10 Sim 6 Cte 1 Entero Sí 5 10 base 1 2 3 4 5 6 QoS medio 1.97 6.57 2.23 3.20 5.81 5.43 5.96 Potencia consumida media (W) 4624.32 851.60 1563.05 993.75 844.24 855.64 910.74 Tiempo de computación (s) - 8.46 52.39 51.87 3.13 42.19 40.41 Evolución media coste (%) - 35.29 31.75 6.79 3.20 42.61 22.65 Coste total medio controlador - 1077876 1373037 1248900 1069072 1086999 1095186 Para un contexto en el que tenemos esta llegada de tareas constantes, es decir, en el que la demanda es estática en el tiempo, el controlador que parece más indicado es el de la Simulación 4 (4.2.1), ya que mantiene el QoS por debajo de 10 (valor deseado), teniendo la potencia y coste más bajos. El mejor QoS se obtiene como era de esperar con la estrategia base, en la que dejamos encendidos todos los servidores. Esta estrategia realmente está muy descompensada, ya que, por ejemplo, en la Simulación 2 o 3 (4.1.2) obtenemos unos valores muy parecidos de QoS con un consumo de menos de un tercio y un cuarto, respectivamente. Otra ventaja del controlador entero es la mayor velocidad de computación con respecto al controlador binario. Podemos observar que la mayor evolución en el coste la tienen los controladores binarios, lo cual es consecuente con el mayor número de posibles soluciones que pueden adaptar los individuos en el problema de optimización. El coste total del controlador se mantiene muy parecido en los mejores casos (1, 4, 5, 6). 83 84 Capítulo 5. Resultados Tabla 5.2 Tabla 2. Tareas constantes, con escenarios (Simulaciones base, 7, 8, 9). Tareas Escenarios Tipo Reseeding NC NP Sim 7 Cte 10 Entero No 1 10 Sim 8 Cte 10 Entero No 5 10 Sim 9 Cte 10 Entero Sí 5 10 base 7 8 9 QoS medio 1.97 2.15 2.10 2.20 Potencia consumida media (W) 4624.32 2309.99 2497.24 2459.28 Tiempo de computación (s) - 26.56 316.96 319.74 Evolución media coste (%) - 0.3 16.67 15.55 Coste total medio controlador - 36161565 38780293 38079400 El controlador que sale mejor parado en esta comparación es el de la Simulación 7 (4.3.1), que consigue un gran valor de rendimiento con una potencia y coste un poco más reducido que en los otros casos. De todas formas, el rendimiento es muy conservador, siendo en este caso más óptimo el usar una solución sin escenarios (1-6). El tiempo de computación es extremadamente alto en estos casos, especialmente con Nc=5. En conclusión, podemos ver que, en general, los controladores con Nc=1 se comportan correctamente con un poco menos de coste, lo que puede ser también debido a que en Nc>1 tengamos más posibles soluciones y sea más complicado llegar al óptimo. Tabla 5.3 Tabla 3. Tareas no constantes, sin escenarios (Simulaciones base, 10, 11, 12, 13, 14, 15). Tareas Escenarios Tipo Reseeding NC NP Sim 10 Cambia 1 Binario No 1 10 Sim 11 Cambia 1 Binario No 3 10 Sim 12 Cambia 1 Binario Sí 3 10 Sim 13 Cambia 1 Entero No 1 10 Sim 14 Cambia 1 Entero No 5 10 Sim 15 Cambia 1 Entero Sí 5 10 base 10 11 12 13 14 15 QoS medio 2.47 22.58 13.77 23.90 19.23 14.25 13.23 Potencia consumida media (W) 4828.39 1452.32 1960.82 1501.87 1430.44 1499.09 1611.34 Tiempo de computación (s) - 8.50 52.88 53.18 2.64 41.13 41.23 Evolución media coste (%) - 13.63 18.40 9.41 1.87 24.03 24.23 Coste total medio controlador - 1780739 1974902 1779798 1751362 1800945 1863453 En el caso con tareas cambiantes, el QoS está por encima del valor deseado (10) en casi todos los casos, excepto el caso base. Es evidente que el controlador no consigue adaptarse bien a la demanda con las estimaciones de Wk y Lk , ya que sólo podemos basarnos en datos del pasado, y actualizarnos cada 100 iteraciones, estimando mediante media móvil. Para mejorar este rendimiento, tendríamos que utilizar otro sistema para calcular estos valores, tal vez, basándonos en datos del pasado. Al igual que en la Tabla 5.1, el controlador entero con Nc=1es el que sale mejor parado en eficiencia. 85 Tabla 5.4 Tabla 4. Tareas no constantes, con escenarios (Simulaciones base, 16, 17, 18). Tareas Escenarios Tipo Reseeding NC NP Sim 16 Cambia 10 Entero No 1 10 Sim 17 Cambia 10 Entero No 5 10 Sim 18 Cambia 10 Entero Sí 5 10 base 16 17 18 QoS medio 2.47 3.60 2.89 3.12 Potencia consumida media (W) 4828.39 2856.42 2922.64 3257.27 Tiempo de computación (s) - 25.71 314.05 305.81 Evolución media coste (%) - 1.50 11.36 7.55 Coste total medio controlador - 42047827 42282671 45658203 El controlador con escenarios sí consigue garantizar un QoS adecuado para el sistema, reduciendo en gran medida la potencia generada en el controlador base. En todos los casos, los controladores diseñados mejoran considerablemente en eficiencia al controlador base, que garantiza valores muy bajos de QoS , pero consumiendo una potencia muy alta. En los casos en los que es necesario más rendimiento (tareas no constantes), el controlador con escenarios garantiza el QoS deseado con un consumo mucho menor. 6 Conclusiones E n este trabajo, presentamos un algoritmo válido para tratar el problema de control de centros de datos. Primero, hemos desarrollado un modelo de un centro de datos que puede ser usado para simular el comportamiento de estas infraestructuras, y así, poder desarrollar algoritmos y controladores para gestionarlos de forma eficaz y eficiente. Luego, hemos implementado un algoritmo genético que acepta variables entera y reales, el MI-LXPM, obteniendo grandes resultados en los problemas de optimización, pese a tener un gran número de soluciones posibles por donde buscar en muchos de los casos tratados. El algortimo siempre ha mostrado una buena convergencia. Este optimizador, lo hemos usado para resolver la función de coste de un MPC, con el que hemos hecho pruebas para controlar el modelo del centro de datos desarrollado y validarlo en diferentes simulaciones. Hemos obtenido resultados interesantes que validan el enfoque y abren otras vías de investigación futuras para mejorar el diseño de los sistemas de gestión y acercarnos más a resolver el problema real que presenta esta industria, disminuyendo costes y mejorando el rendimiento, lo cual puede generar grandes ahorros en beneficio del usuario, de la empresa y del planeta. Como trabajos futuros, tenemos varios frentes pendientes que no hemos tratado en el proyecto y podrían servir como nueva línea de investigación para mejorar el desarrollo logrado. Por ejemplo, empezando por el algoritmo MI-LXPM, sería interesante poder desarrollar una condicion de parada diferente de un número limitado de iteraciones, como puede ser parar la optimización cuando el coste deje de converger, como se hace en multitud de algoritmos iterativos de este tipo. También nos hubiera gustado analizar mejor los parámetros de este algoritmo, y hacer un mayor número de pruebas comparando los valores de estos. De los problemas más importantes que encontramos en los resultados obtenidos en las simulaciones es la incapacidad del controlador para adaptarse a una demanda cambiante. Pensamos que esta estimación de demanda se podría abordar de múltiples formas. Por ejemplo, realizando estimaciones basadas en datos del pasado, que en el caso de los centros de datos pueden ser realmente fáciles de obtener, entrenando con estos datos redes neuronales que luego estimen la demanda en el futuro [24]. Finalmente, una gran limitación que hemos tenido es el alto tiempo de procesamiento que tienen algunas de las simulaciones que hemos realizado. Una línea de mejora de este sistema para el futuro, puede ser el uso de estrategias de multihilo para realizar la optimización, intentando paralelizar al máximo la computación, ya sea usando los hilos de la CPU o directamente una GPU. 87 Apéndice A Modelo Centro de Datos A.1 data_center.py 1# -*- coding: utf-8 -*- 2""" 3Created on Sun Dec 5 22:05:01 2021 4 5@author: EQUIPO 6""" 7from src.server import Server 8import config.params as params 9 10 M_min =params.mu /params.ka 11 12 class DataCenter: 13 def __init__(self, M): 14 ErrorMessage ="M doesnt satisfy queue restrictions" 15 assert(M >= M_min),ErrorMessage 16 self.__list_servers =[] 17 self.__M =M 18 for iin range (M): 19 self.__list_servers.append(Server(i)) 20 21 def print_servers_state(self): 22 list_servers =self.list_servers() 23 for iin range(self.__M): 24 if list_servers[i].get_task(): 25 print(list_servers[i].state(), 26 ", Task:", list_servers[i].get_task().get_ID(), "Current Workdone: ", list_servers[i].get_task().get_current_workload()),→ 27 else: 28 print(list_servers[i].state()) 29 30 def power_consumption(self): 31 power = 0 32 for iin range(self.__M): 33 power =power +self.__list_servers[i].power_consumption() 34 return power 35 36 def update(self): 37 list_servers =self.list_servers() 38 for iin range(self.__M): 39 list_servers[i].update() 89 96 Capítulo A. Modelo Centro de Datos 31 for i, value in enumerate(column_data): 32 data[i + 1].append(value) 33 34 # Escribe los datos actualizados de nuevo en el archivo CSV 35 with open(filename, 'w', newline='')as csvfile: 36 writer =csv.writer(csvfile) 37 writer.writerows(data) 38 39 print(f"Columna '{header}'agregada exitosamente al archivo '{filename}'.") 40 41 except ValueError as e: 42 print(f"Error: {str(e)}") Apéndice B Control y simulaciones Centro de Datos B.1 main_simulation.py 1import importlib 2import datetime 3import numpy as np 4import matplotlib.pyplot as plt 5import config.params as params 6from src.data_center import DataCenter 7from src.probability_functions import arrived_tasks, time_between_arrivals, arrived_tasks_static, func_workload,→ 8from src.task import Task 9from mi_lxpm.src import laplace_crossover as lx 10 from mi_lxpm.src import power_mutation as pm 11 from mi_lxpm.src import tournament 12 from mi_lxpm.src import truncation as tr 13 from mi_lxpm.src import utils 14 from src.dc_utils import add_columns_to_csv 15 16 # Controller initialization 17 mi_lxpm_config =utils.config 18 controller_type =[] 19 20 p=importlib.import_module(f'mi_lxpm.src.problems.{mi_lxpm_config.problem}') 21 22 if mi_lxpm_config.problem == "problem_datacenter_binary": 23 controller_type ="binary" 24 elif mi_lxpm_config.problem == "problem_datacenter_integer": 25 controller_type ="integer" 26 27 pop_size =p.POP_SIZE if hasattr(p, 'POP_SIZE')else mi_lxpm_config.pop_factor *\ 28 len(p.INT_VARS) 29 elite_size =int(np.ceil(mi_lxpm_config.elite_factor *pop_size)) 30 31 M=params.M 32 DC =DataCenter(M) 33 NC =params.NC 34 35 time_sim =[] 36 power_consumption_sim =[] 37 queue_length_sim =[] 38 pool_length_sim =[] 39 COP_sim =[] 97 98 Capítulo B. Control y simulaciones Centro de Datos 40 Total_Power_sim =[] 41 ON_servers_sim =[] 42 idle_servers_sim =[] 43 QoS_sim =[] 44 desired_QoS =[] 45 queue =[] 46 pool =[] 47 Tc_sim =[] 48 Tr_sim =[] 49 Ti_sim =[] 50 score_sim =[] 51 cost_r_sim =[] 52 cost_u_sim =[] 53 new_tasks_number_sim =[] 54 new_tasks_moving_average_list =[] 55 workload_moving_average_list =[] 56 min_servers_estimation_sim =[] 57 controller_cost_evolution =[] 58 59 moving_average_size =params.moving_average_size 60 61 #Read Params 62 Tc =params.Tc0 63 # Tc_sim.append(Tc) 64 Tr =params.Tr0 65 tr_ant =Tr 66 servers_ant =[0]*M 67 68 ts =params.ts 69 tau =params.tau 70 71 #Task preparation 72 # N_task = 26 73 # Interval = [] 74 # NumEntryTask = 0 75 task_index = 0 76 77 # for i in range(N_task): 78 # Interval.append(time_between_arrivals()) 79 80 # Arrivals_iteration = [] 81 # Acum = 0 82 83 # for i in range(N_task): 84 # Arrivals_iteration.append(Acum + Interval[i]) 85 # Acum = Arrivals_iteration[i] 86 87 wk =params.mu 88 lk =1/params.ka 89 new_tasks_moving_average_list.append(lk) 90 workload_moving_average_list.append(wk) 91 92 for kin range(params.sim_time_intervals): 93 94 time_sim.append(k) 95 # Initial input controller 96 if k== 0: 97 if controller_type == "binary":# El vector U es una lista de binarios y la Tc 98 n_servers = 2 B.1 main_simulation.py 99 99 servers =[1]*n_servers +[0]*(M -n_servers) 100 t=DC.switch(servers, k) 101 servers.append(Tr) 102 u=servers 103 elif controller_type == "integer":# El vector U es un entero n_servers y la Tc 104 n_servers = 4 105 servers =[1]*n_servers +[0]*(M -n_servers) 106 t=DC.switch(servers, k) 107 u=[n_servers, Tr] 108 109 receiding_offspring =np.array(u) 110 receiding_offspring =np.tile(receiding_offspring, (int(round(pop_size*params.reseeding_percentage)), params.NC)),→ 111 112 #################### Controller ############################# 113 if k%params.controller_sample_time == 0: 114 # wk = params.mu 115 # lk = 1 / params.ka * 5 116 wk =sum(workload_moving_average_list) /len(workload_moving_average_list) 117 lk =sum(new_tasks_moving_average_list) /len(new_tasks_moving_average_list) 118 min_servers =np.ceil(wk*(1/params.desired_QoS +lk)) 119 print(min_servers) 120 scenarios =[] 121 if params.S== 1: 122 scenarios.append([wk, lk]) 123 else: 124 for sin range(params.S): 125 scenarios.append([func_workload(wk), arrived_tasks_static(lk)]) 126 print(np.ceil(scenarios[-1][0]*(1/params.desired_QoS +scenarios[-1][1]))) 127 128 Ti =DC.get_servers_temperature() 129 130 if params.reseeding == True and k> 0: 131 new_offspring =utils.generate(int(round(pop_size*(1-params.reseeding_percentage))), p.INT_VARS, p.L_BOUND, p.U_BOUND),→ 132 offspring =np.concatenate((new_offspring, receiding_offspring)) 133 else: 134 offspring =utils.generate(pop_size, p.INT_VARS, p.L_BOUND, p.U_BOUND) 135 136 score, feasible =utils.evaluate(offspring, p.evaluate, u, Ti, Tc, scenarios, p.MAX) 137 138 fittest =None 139 s_fittest =None 140 141 qt_evals =pop_size 142 143 controller_cost_evolution_instant =[] 144 145 for iin range(0, mi_lxpm_config.max_iterations): 146 score_sort =np.argsort(score) if not p.MAX else np.argsort(score)[::-1] 147 148 if feasible and (fittest is None or (p.MAX and s_fittest <score[score_sort[0]]) or (not p.MAX and s_fittest >score[score_sort[0]])):,→ 149 fittest =offspring[score_sort[0]] 150 s_fittest =score[score_sort[0]] 151 152 elite =offspring[score_sort][0:elite_size] 153 selection =tournament.select( 154 offspring, score, pop_size -elite_size, p.MAX) 100 Capítulo B. Control y simulaciones Centro de Datos 155 156 n_cross =pop_size -elite_size 157 off =lx.crossover(selection[0:n_cross], p.INT_VARS) 158 159 off =pm.mutate(off, p.INT_VARS, p.L_BOUND, p.U_BOUND) 160 161 offspring =tr.truncate(np.vstack((elite, off)), p.INT_VARS) 162 163 score, feasible =utils.evaluate(offspring, p.evaluate, u, Ti, Tc, scenarios, p.MAX) 164 165 qt_evals =qt_evals +pop_size 166 167 controller_cost_evolution_instant.append(s_fittest) 168 169 controller_cost_evolution.append(controller_cost_evolution_instant) 170 171 score_sort =np.argsort(score) if not p.MAX else np.argsort(score)[::-1] 172 173 u=fittest 174 175 # print("best elements: \n") 176 # for element in range(10): 177 # print("element: ", offspring[score_sort[element]], "score: ", score[score_sort[element]]),→ 178 179 # print("worst elements: \n") 180 # for element in range(1, 10): 181 # print("element: ", offspring[score_sort[-element]], "score: ", score[score_sort[-element]]),→ 182 183 print("Iteración:", k, "\n") 184 print("Salida controlador: ", u) 185 print("Coste: ", s_fittest) 186 print("min_servers: ", min_servers) 187 score_sim.append(s_fittest) 188 min_servers_estimation_sim.append(min_servers) 189 190 cost_u = 0 191 cost_r = 0 192 193 if controller_type == "binary":# El vector U es una lista de binarios y la Tc 194 u_servers =u[0:M] 195 Tr =u[M] 196 servers =[int(x) for xin u_servers] # Ouput of MI-LXPM is float 197 print("Accion control servers: ", servers) 198 print("Accion control temp: ", Tr) 199 if params.reseeding_variation == False: 200 last_control_action =u[-(M+1):] 201 receiding_offspring =np.concatenate((u[M + 1:], last_control_action)) 202 receiding_offspring =np.tile(receiding_offspring, (int(round(pop_size*params.reseeding_percentage)), 1)),→ 203 else: 204 receiding_offspring = offspring[score_sort[:int(pop_size*params.reseeding_percentage)]],→ 205 last_control_action =receiding_offspring[:, -(M+1):] 206 receiding_offspring =np.column_stack((receiding_offspring[:, M + 1:], last_control_action)),→ 207 208 elif controller_type == "integer": B.1 main_simulation.py 101 209 Tr =u[1] 210 n_servers =int(u[0]) 211 servers =[1]*n_servers +[0]*(M -n_servers) 212 print("Accion control servers: ", servers) 213 print("Accion control temp: ", Tr) 214 if params.reseeding_variation == False: 215 last_control_action =u[-2:] 216 receiding_offspring =np.concatenate((u[2:], last_control_action)) 217 receiding_offspring =np.tile(receiding_offspring, (int(round(pop_size*params.reseeding_percentage)), 1)),→ 218 else: 219 receiding_offspring = offspring[score_sort[:int(pop_size*params.reseeding_percentage)]],→ 220 last_control_action =receiding_offspring[:, -2:] 221 receiding_offspring =np.column_stack((receiding_offspring[:, 2:], last_control_action)),→ 222 223 224 # print("receiding_offspring: ", receiding_offspring) 225 226 cost_r =cost_r +abs(Tr -tr_ant)*params.lambda_r 227 cost_u =cost_u +np.sum(np.array(servers) != np.array(servers_ant))*params.lambda_u 228 229 cost_u_sim.append(cost_u) 230 cost_r_sim.append(cost_r) 231 232 servers_ant =servers 233 tr_ant =Tr 234 235 reentry_tasks =DC.switch(servers, k) 236 237 #Reparto tareas que se han podido quedar tiradas por apagar el server 238 print("Reentry_tasks:") 239 for task in reentry_tasks: 240 if task: 241 print(task.get_ID()) 242 243 print("\n") 244 245 removed_task =[] 246 247 for task in reentry_tasks: 248 if task: 249 print(task) 250 if not task in DC.get_task_list() and not task in removed_task: 251 removed_task_id =task.get_ID() 252 print("Add to queue task id from switched off server:", removed_task_id, task) 253 task.unassign() 254 queue.insert(0, task) 255 pool.remove(task) 256 removed_task.append(task) 257 258 # Pool update ############################################## 259 completed_index =[] 260 for task in pool: 261 if task.is_completed() == True: 262 completed_index.append(pool.index(task)) 263 QoS_sim.append(task.get_time()) 264 desired_QoS.append(params.desired_QoS) 102 Capítulo B. Control y simulaciones Centro de Datos 265 else: 266 task.update() 267 268 #Genialidad encontrada en Stack Overflow para eliminar las tareas 269 for index in sorted(completed_index, reverse=True): 270 pool.pop(index) 271 272 # Queue update ############################################## 273 for task in queue: 274 task.update() 275 276 avaliable =DC.servers_avaliable() 277 278 if avaliable>0: 279 # print("Servers avaliable:", avaliable) 280 for iin range(avaliable): 281 if queue: 282 # print("Add to pool QUEUE task id:", queue[0].get_ID()) 283 pool.append(queue[0]) 284 queue.pop(0) 285 avaliable =avaliable - 1 286 287 # Tasks arrivals ######################################## 288 # if (k == Arrivals_iteration[NumEntryTask]): 289 # # print("New task") 290 # new_tasks = 0 291 # NumEntryTask = NumEntryTask + 1 292 # new_task = new_task + 1 293 # else: 294 # new_tasks = 0 295 296 new_tasks =arrived_tasks(k, params.ka) 297 new_tasks_number_sim.append(new_tasks) 298 299 if len(new_tasks_moving_average_list) >moving_average_size: 300 new_tasks_moving_average_list.pop(0) 301 new_tasks_moving_average_list.append(new_tasks) 302 else: 303 new_tasks_moving_average_list.append(new_tasks) 304 305 # print("New tasks:", new_tasks) 306 task_not_assigned = 0 307 # print("Servers avaliable:", avaliable) 308 for iin range(new_tasks): 309 task =Task(task_index) 310 311 if len(workload_moving_average_list) >moving_average_size: 312 workload_moving_average_list.pop(0) 313 workload_moving_average_list.append(task.get_workload()) 314 else: 315 workload_moving_average_list.append(task.get_workload()) 316 317 if avaliable > 0: 318 # print("Add to pool NEW task id:", task.get_ID()) 319 pool.append(task) 320 avaliable =avaliable - 1 321 else: 322 # print("Add to queue NEW task id:", task.get_ID()) 323 queue.append(task) B.1 main_simulation.py 103 324 task_index =task_index + 1 325 326 for iin range(len(pool)): 327 if pool[i].is_assigned() == False: 328 task_not_assigned =task_not_assigned + 1 329 330 gap =DC.servers_avaliable() -task_not_assigned 331 332 # # Print pool 333 # print("Pool: \n") 334 # for task in pool: 335 # print(task.get_ID(), task.is_assigned()) 336 337 # print("\n") 338 339 # # Print queue 340 # print("Queue: \n") 341 # for task in queue: 342 # print(task.get_ID(), task.is_assigned()) 343 344 # print("\n") 345 346 # # Print gap 347 # print("Gap:", gap, "\n") 348 349 # Tasks assignements ######################################## 350 # Guess task with maximum workload 351 if gap>0: 352 workload =[] 353 for task in pool: 354 if task.is_assigned() == False: 355 workload.append(task.get_workload()) 356 357 # Share task with maximum workload 358 if len(workload) != 0: 359 max_wl =max(workload) 360 max_index =workload.index(max_wl) 361 N=gap + 1 362 pool[max_index].share_workload() 363 364 for task in pool: 365 if gap == 0: 366 if task.is_assigned() == False: 367 for server in DC.list_servers(): 368 if server.state() == 'idle': 369 success =server.make_request(task) 370 if server.get_task() == None: 371 success =False 372 if not success: 373 print("[Main Simulation] Error al asignar tarea, servidor no está en idle"),→ 374 print(DC.print_servers_state()) 375 break 376 377 elif gap>0: 378 # Assign task with maximum workload 379 if task.is_assigned() == False and task.is_shared() == True: 380 n= 0 381 for server in DC.list_servers(): 104 Capítulo B. Control y simulaciones Centro de Datos 382 if server.state() == 'idle': 383 success =server.make_request(task) 384 if server.get_task() == None: 385 success =False 386 # print(["[Main Simulation] Servidor: ", server.get_index(), "comparte tarea: ", task.get_ID()]),→ 387 if not success: 388 print("[Main Simulation] Error al asignar tarea, servidor no está en idle"),→ 389 print(DC.print_servers_state()) 390 n=n+ 1 391 if n== N: 392 break 393 394 elif task.is_assigned() == False and task.is_shared() == False: 395 for server in DC.list_servers(): 396 if server.state() == 'idle': 397 success =server.make_request(task) 398 if server.get_task() == None: 399 success =False 400 if not success: 401 print("[Main Simulation] Error al asignar tarea, servidor no está en idle"),→ 402 print(DC.print_servers_state()) 403 break 404 405 if k%params.controller_sample_time == 0: 406 print("Pool after controller: length =",len(pool), "\n") 407 for task in pool: 408 print(task.get_ID(), task.is_assigned(), task.is_shared(), task.get_server_index(), task),→ 409 410 print("Tasks list: ","\n") 411 for task in DC.get_task_list(): 412 if task: 413 print(task.get_ID(), task) 414 415 #DC.print_servers_state() 416 #print("\n") 417 418 ON_servers_sim.append(DC.number_servers_on()) 419 idle_servers_sim.append(DC.number_servers_in_state("idle")) 420 queue_length_sim.append(len(queue)) 421 pool_length_sim.append(len(pool)) 422 423 # Update time in data center 424 DC.update() 425 426 # Thermal update in data center 427 DC.thermal_update(Tc) 428 429 Tc =ts *(1/tau) *(Tr-Tc) +Tc 430 Tc_sim.append(Tc) 431 Tr_sim.append(Tr) 432 433 COP = 0.0068*Tc**2 + 0.0008*Tc + 0.458 434 COP_sim.append(COP) 435 436 Total_Power =DC.power_consumption()*(1+1/COP) B.1 main_simulation.py 105 437 Total_Power_sim.append(Total_Power) 438 439 Ti_sim.append(DC.get_servers_temperature()) 440 441 # Save simulation CSV 442 now =datetime.datetime.now() 443 timestamp =now.strftime("%Y-%m-%d_%H-%M-%S") 444 filename =f"simulation_data/sim_{timestamp}.csv" 445 446 add_columns_to_csv(filename, "time_sim", time_sim) 447 add_columns_to_csv(filename, "queue_length", queue_length_sim) 448 add_columns_to_csv(filename, "pool_length", pool_length_sim) 449 add_columns_to_csv(filename, "total_power", Total_Power_sim) 450 add_columns_to_csv(filename, "cop_sim", COP_sim) 451 add_columns_to_csv(filename, "tc_sim", Tc_sim) 452 add_columns_to_csv(filename, "tr_sim", Tr_sim) 453 add_columns_to_csv(filename, "on_servers_sim", ON_servers_sim) 454 add_columns_to_csv(filename, "idle_servers_sim", idle_servers_sim) 455 add_columns_to_csv(filename, "new_tasks_number", new_tasks_number_sim) 456 457 # Save Ti CSV 458 filename =f"simulation_data/Ti_sim_{timestamp}.csv" 459 columns =[[] for _in range(M)] 460 461 # Llenar las columnas con los elementos correspondientes de cada lista interna 462 for row in Ti_sim: 463 for i, value in enumerate(row): 464 columns[i].append(value) 465 466 for server in range(M): 467 header ="ti_sim_" +str(server) 468 add_columns_to_csv(filename, header, columns[server]) 469 470 # Save QoS csv 471 filename =f"simulation_data/QoS_sim_{timestamp}.csv" 472 add_columns_to_csv(filename, "QoS_sim", QoS_sim) 473 add_columns_to_csv(filename, "Desired_QoS", desired_QoS) 474 475 # Save score csv 476 filename =f"simulation_data/score_sim_{timestamp}.csv" 477 add_columns_to_csv(filename, "score", score_sim) 478 add_columns_to_csv(filename, "cost_r", cost_r_sim) 479 add_columns_to_csv(filename, "cost_u", cost_u_sim) 480 add_columns_to_csv(filename, "min_servers_estimation", min_servers_estimation_sim) 481 482 # Save params csv 483 filename =f"simulation_data/params_sim_{timestamp}.csv" 484 add_columns_to_csv(filename, "controller_type", [controller_type]) 485 add_columns_to_csv(filename, "controller_max_iterations", [mi_lxpm_config.max_iterations]) 486 add_columns_to_csv(filename, "controller_pop_size", [pop_size]) 487 add_columns_to_csv(filename, "NC", [params.NC]) 488 add_columns_to_csv(filename, "NP", [params.NP]) 489 add_columns_to_csv(filename, "moving_average_size", [params.moving_average_size]) 490 add_columns_to_csv(filename, "S", [params.S]) 491 add_columns_to_csv(filename, "lambda_u", [params.lambda_u]) 492 add_columns_to_csv(filename, "lambda_r" , [params.lambda_r]) 493 add_columns_to_csv(filename, "reseeding", [params.reseeding]) 494 add_columns_to_csv(filename, "reseeding_percentage", [params.reseeding_percentage]) 495 add_columns_to_csv(filename, "reseeding_variation", [params.reseeding_variation]) 112 Capítulo B. Control y simulaciones Centro de Datos 44 if min_servers >params.M: 45 min_servers =params.M 46 47 score, constraint_sum =eval_scenario(x, x_act, ti_act, tc_act, min_servers) 48 49 total_score =total_score +score 50 total_constraint_sum =total_constraint_sum +constraint_sum 51 52 return total_score, total_constraint_sum 53 54 def eval_scenario(x, x_act, ti_act, tc_act, min_servers): 55 # Inicializa una matriz de ceros con la forma deseada (200 filas y M columnas) 56 servers_matrix =np.zeros((POP_SIZE, M), dtype=int) 57 58 # Itera a través de las filas de x 59 for i, row in enumerate(x[:,:1]): 60 N=int(row[0]) # Obtén el valor de número de servidores 61 if(N) >M: # Si es mayor de 10, truncamos, de todas formas el algoritmo desechará esta opción,→ 62 N=M 63 elif(N) < 0: 64 N= 0 65 # Aplicar la lógica para crear la fila correspondiente en servers_matrix 66 servers =[1]*N+[0]*(M -N) 67 servers_matrix[i] =servers 68 69 Pi =(a1+a2)*servers_matrix # Pi es el numero de servidores que estaran encendidos por a1 70 Tr =x[:, 1] 71 72 # print("initial_server_matrix: ", servers_matrix) 73 74 # Ti prediction 75 Ti =ti_act +ts/Kt *((cp*qa)*(tc_act-ti_act) +Pi) 76 ti_act =Ti 77 78 # Tc prediction 79 Tc =tc_act +ts/tau *(Tr -tc_act) 80 tc_act =np.array(Tc) 81 82 # CoP prediction 83 CoP = 0.0068*Tc**2 + 0.0008*Tc + 0.458 84 total_power_consumption =np.sum(Pi *(1 + 1/CoP[:, np.newaxis]), axis=1) 85 86 # Constraints INITIALIZATION 87 constraint1 = -x[:, 0]# Number of servers between 0 and M 88 constraint2 =x[:, 0]-M 89 constraint3 = 288 - x[:, 1]# Tr between 288K and 298K 90 constraint4 =x[:, 1]- 298 91 constraint5 =min_servers -x[:, 0]# QoS constraints 92 constraint6 =Ti - 353 # Ti <= 353K 93 94 constraint1_ant =constraint1 95 constraint2_ant =constraint2 96 constraint3_ant =constraint3 97 constraint4_ant =constraint4 98 constraint5_ant =constraint5 99 constraint6_ant =constraint6 100 101 # print("X: ", x) B.4 problem_datacenter_integer.py 113 102 103 # delta U (number off-on commutation) 104 servers_act =np.array(x_act[0]) 105 servers_control =np.array(x[:, 0]) 106 # print("servers_control: ", servers_control) 107 # print("servers_act: ", servers_act) 108 delta_u =abs(servers_control -servers_act) 109 servers_act =servers_control 110 111 # print('[F_eval] delta u: ', delta_u, '\n') 112 113 # delta Tr (difference between Tr_act and candidate Tr) 114 delta_r =abs(x_act[1]-Tr) 115 Tr_act =Tr 116 117 # print('[F_eval] delta r: ', delta_r, '\n') 118 119 j_c = 0 120 121 # print("NP:", NP) 122 123 for iin range(NP-1): 124 if i%params.controller_sample_time ==0and i!= 0: 125 if j_c <(NC-1): 126 Tr =x[:, j_c*2+3] 127 servers_matrix =np.zeros_like(servers_matrix) 128 # Itera a través de las filas de x 129 for k, row in enumerate(x[:,(j_c*2+2):(j_c*2+3)]): 130 N=int(row[0]) # Obtén el valor de número de servidores 131 # print("N: ", "(",k,")", N) 132 if(N) >M: # Si es mayor de M, truncamos, de todas formas el algoritmo desechará esta opción,→ 133 N=M 134 elif(N) < 0: 135 N= 0 136 # Aplicar la lógica para crear la fila correspondiente en servers_matrix 137 servers =[1]*N+[0]*(M -N) 138 servers_matrix[k] =servers 139 # print("Servers_matrix: ", "(",k,")", servers_matrix) 140 Pi =(a1+a2)*servers_matrix 141 142 # Ti prediction 143 Ti =ti_act +ts/Kt *((cp*qa)*(np.tile(tc_act.reshape(-1,1), (1, M))-ti_act) +Pi) 144 ti_act =Ti 145 146 # print('[F_eval] tc_act: ', tc_act, '\n') 147 # print('[F_eval] Tr: ', Tr, '\n') 148 149 # Tc prediction 150 Tc =tc_act +ts/tau *(Tr -tc_act) 151 tc_act =Tc 152 153 # CoP prediction 154 CoP = 0.0068*Tc**2 + 0.0008*Tc + 0.458 155 total_power_consumption =total_power_consumption +np.sum(Pi *(1 + 1/CoP[:, np.newaxis]), axis=1),→ 156 157 # print("X:", x) 158 # print("Pi:", Pi) 114 Capítulo B. Control y simulaciones Centro de Datos 159 # print("Total power consumption:", total_power_consumption) 160 161 if i%params.controller_sample_time ==0and i!= 0: 162 if j_c <(NC-1): 163 # Constraint actualization 164 constraint1 = -x[:, j_c*2+2]# Number of servers between 0 and M 165 constraint2 =x[:, j_c*2+2]-M 166 constraint3 = 288 - x[:, j_c*2+3]# Tr between 288K and 298K 167 constraint4 =x[:, j_c*2+3]- 298 168 constraint5 =min_servers -x[:, j_c*2+2]# QoS constraints 169 constraint6 =Ti - 353 # Ti <= 353K 170 171 # print("Constraint1_ant: ", constraint1_ant, "\n") 172 # print("Constraint1: ", constraint1, "\n") 173 174 for kin range(len(constraint1)): 175 if constraint1[k] <constraint1_ant[k]: 176 constraint1[k] =constraint1_ant[k] 177 178 constraint1_ant =constraint1 179 # print("Constraint1 new: ", constraint1, "\n") 180 181 # print("Constraint2_ant: ", constraint2_ant, "\n") 182 # print("Constraint2: ", constraint2, "\n") 183 184 for kin range(len(constraint2)): 185 if constraint2[k] <constraint2_ant[k]: 186 constraint2[k] =constraint2_ant[k] 187 188 constraint2_ant =constraint2 189 # print("Constraint2 new: ", constraint2, "\n") 190 191 # print("Constraint3_ant: ", constraint3_ant, "\n") 192 # print("Constraint3: ", constraint3, "\n") 193 194 for kin range(len(constraint3)): 195 if constraint3[k] <constraint3_ant[k]: 196 constraint3[k] =constraint3_ant[k] 197 198 constraint3_ant =constraint3 199 # print("Constraint3 new: ", constraint3, "\n") 200 201 # print("Constraint4_ant: ", constraint4_ant, "\n") 202 # print("Constraint4: ", constraint4, "\n") 203 204 for kin range(len(constraint4)): 205 if constraint4[k] <constraint4_ant[k]: 206 constraint4[k] =constraint4_ant[k] 207 208 constraint4_ant =constraint4 209 # print("Constraint4 new: ", constraint4, "\n") 210 # print("X: ", x) 211 212 # print("Constraint5_ant: ", constraint5_ant, "\n") 213 # print("Constraint5: ", constraint5, "\n") 214 215 for kin range(len(constraint5)): 216 if constraint5[k] <constraint5_ant[k]: 217 constraint5[k] =constraint5_ant[k] B.4 problem_datacenter_integer.py 115 218 219 constraint5_ant =constraint5 220 # print("Constraint5 new: ", constraint5, "\n") 221 222 # print("Constraint6_ant: ", constraint6_ant, "\n") 223 # print("Constraint6: ", constraint6, "\n") 224 225 for kin range(len(constraint6)): 226 for jin range(len(constraint6[k])): 227 if constraint6[k][j] <constraint6_ant[k][j]: 228 constraint6[k][j] =constraint6_ant[k][j] 229 230 constraint6_ant =constraint6 231 # print("Constraint6 new: ", constraint6, "\n") 232 233 # delta U (number off-on commutation) 234 servers_control =np.array(x[:, j_c*2+2]) 235 # print("servers_control: ", servers_control) 236 # print("servers_act: ", servers_act) 237 delta_u =delta_u +abs(servers_control -servers_act) 238 servers_act =servers_control 239 240 # delta Tr (difference between Tr_act and candidate Tr) 241 delta_r =delta_r +abs(Tr_act -Tr) 242 Tr_act =Tr 243 # print('[F_eval] delta u: ', delta_u, '\n') 244 # print('[F_eval] delta r: ', delta_r, '\n') 245 246 j_c =j_c + 1 247 248 # Temp constraint actualization 249 constraint6 =Ti - 353 # Ti <= 353K 250 251 for kin range(len(constraint6)): 252 for jin range(len(constraint6[k])): 253 if constraint6[k][j] <constraint6_ant[k][j]: 254 constraint6[k][j] =constraint6_ant[k][j] 255 256 constraints =np.hstack((constraint1.reshape(-1,1), constraint2.reshape(-1,1), constraint3.reshape(-1,1), constraint4.reshape(-1,1), constraint5.reshape(-1,1), constraint6)) ,→ ,→ 257 258 constraints =np.absolute(constraints.clip(min=0)) 259 260 # print('[F_eval] total consumption: ', total_power_consumption, '\n') 261 262 lambda_u =params.lambda_u 263 264 # print('[F_eval] delta u: ', delta_u, '\n') 265 266 lambda_r =params.lambda_r 267 268 # print('[F_eval] delta r: ', delta_r, '\n') 269 270 y=total_power_consumption +lambda_u*delta_u +lambda_r*delta_r 271 272 return y, np.sum(constraints, axis=1) 116 Capítulo B. Control y simulaciones Centro de Datos B.5 get_mean_data.py 1import os 2import pandas as pd 3import shutil 4 5# Ruta de la carpeta que contiene los archivos de simulación 6folder_path ="simulation_data" 7 8# Obtener la lista de archivos en la carpeta 9file_list =os.listdir(folder_path) 10 11 # Crear una lista de tipos de archivo permitidos 12 tipos_permitidos =["QoS","sim","score","params"]# Agrega los tipos permitidos aquí 13 14 # Crear un diccionario para almacenar los DataFrames de todos los archivos por tipo 15 dataframes_by_type ={} 16 17 # Variable para almacenar la suma de los valores de la primera columna 18 total_sum = 0 19 percentaje_sum = 0 20 21 # Contador para llevar el registro de cuántos archivos "QoS" se encontraron 22 qos_file_count = 0 23 qos_count = 0 24 25 # Iterar a través de los archivos de simulación y cargar los DataFrames 26 for filename in file_list: 27 # Obtener el tipo de archivo (QoS, normal, score, etc.) del nombre del archivo 28 file_type =filename.split("_")[0] 29 30 # Verificar si el tipo de archivo está en la lista de tipos permitidos 31 if file_type not in tipos_permitidos: 32 continue # Saltar este archivo si no es un tipo permitido 33 34 # Verificar si el tipo de archivo es "QoS" 35 if file_type == "QoS": 36 # Leer el archivo de simulación y convertir la primera columna en valores numéricos 37 df =pd.read_csv(os.path.join(folder_path, filename), skiprows=[0]) 38 first_column =df.iloc[:, 0] 39 40 # Calcular la suma de la primera columna 41 total_sum += first_column.sum() 42 43 # Incrementar el contador de archivos "QoS" encontrados 44 qos_file_count += 1 45 qos_count += len(first_column) 46 47 # Contador para valores mayores de 10 48 qos_percentaje =(first_column > 10).sum() /len(first_column) 49 percentaje_sum += qos_percentaje 50 51 elif file_type == "params": 52 destination_file =f"average_simulation_data/{file_type}_simulation_data.csv" 53 shutil.copy2(f"simulation_data/{filename}", destination_file) 54 55 elif file_type == "sim": 56 df =pd.read_csv(os.path.join(folder_path, filename), skiprows=[0]) B.5 get_mean_data.py 117 57 third_column =df.iloc[:, 2] 58 59 # Verificar si hay valores menores que el valor mínimo deseado 60 rows_with_invalid_values =third_column[third_column > 25.0] 61 if not rows_with_invalid_values.empty: 62 print(f"Valores no deseados encontrados en el archivo: {filename}") 63 print(f"Número de filas con valores no deseados: {len(rows_with_invalid_values)}") 64 print(f"Filas con valores no deseados: {','.join(map(str, rows_with_invalid_values.index))}"),→ 65 66 # Leer el archivo de simulación y convertir las columnas en tipos numéricos 67 df =pd.read_csv(os.path.join(folder_path, filename)) 68 df =df.apply(pd.to_numeric, errors='coerce') 69 70 # Almacenar el DataFrame en el diccionario usando el tipo de archivo como clave 71 if file_type not in dataframes_by_type: 72 dataframes_by_type[file_type] =[df] 73 else: 74 dataframes_by_type[file_type].append(df) 75 else: 76 # Leer el archivo de simulación y convertir las columnas en tipos numéricos 77 df =pd.read_csv(os.path.join(folder_path, filename)) 78 df =df.apply(pd.to_numeric, errors='coerce') 79 80 # Almacenar el DataFrame en el diccionario usando el tipo de archivo como clave 81 if file_type not in dataframes_by_type: 82 dataframes_by_type[file_type] =[df] 83 else: 84 dataframes_by_type[file_type].append(df) 85 86 # Calcular el promedio de cada celda en la misma posición de todos los DataFrames por tipo de archivo,→ 87 for file_type, df_list in dataframes_by_type.items(): 88 num_rows =min(df.shape[0]for df in df_list) # Usar el número mínimo de filas 89 num_cols =df_list[0].shape[1] 90 average_df =pd.DataFrame(columns=df_list[0].columns) 91 92 for row in range(num_rows): 93 for col in range(num_cols): 94 cell_values =[df.iloc[row, col] for df in df_list] 95 average_value =sum(cell_values) /len(cell_values) 96 average_df.loc[row, average_df.columns[col]] =average_value 97 98 # Guardar el DataFrame promedio en un archivo CSV específico para el tipo 99 average_df.to_csv(f"average_simulation_data/average_{file_type}_simulation_data.csv", index=False),→ 100 101 # Calcular la media de la primera columna de todos los archivos "QoS" encontrados 102 if qos_count > 0: 103 average_value =total_sum /qos_count 104 average_percentage =percentaje_sum /qos_file_count 105 print("Mean QoS:", average_value) 106 print("Percentage QoS:", average_percentage) 107 108 # Specify the file path where you want to save the values 109 file_path ="average_simulation_data/qos_values.txt" 110 111 # Open the file in write mode 112 with open(file_path, "w")as file: 118 Capítulo B. Control y simulaciones Centro de Datos 113 # Write the average values to the file 114 file.write(f"Mean QoS: {average_value}\n") 115 file.write(f"Percentage QoS: {average_percentage}\n") 116 117 else: 118 print("No se encontraron archivos de tipo 'QoS'.") B.6 batch_simulation.sh 1#!/bin/bash 2 3# Number of iterations 4iterations=10 5 6# Path to your Python script 7python_script="main_simulation.py" 8 9# Record the start time 10 start_time=$(date +%s) 11 12 # Loop through the specified number of iterations 13 for ((i=1; i<=$iterations; i++));do 14 echo "Running iteration $i" 15 python "$python_script" 16 done 17 18 # Record the end time 19 end_time=$(date +%s) 20 21 # Calculate the elapsed time in seconds 22 elapsed_time=$((end_time -start_time)) 23 24 echo "All iterations completed, took $elapsed_time seconds" Índice de Figuras 1.1 Energía consumida en un Centro de Datos típico [5] 2 2.1 Modelo basado en única cola con múltiples servidores. 3 2.2 Estados y transiciones en un servidor. 4 2.3 Ejemplo clases Server yTask 7 3.1 Estrategia del MPC [16] 10 3.2 Esquema de funcionamiento de un algoritmo genético [18] 12 3.3 Función de densidad de la distribución de Laplace (a=0,b=0.5,b=1)[19] 12 4.1 Simulación 1. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 22 4.2 Simulación 1. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 23 4.3 Simulación 1. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 23 4.4 Simulación 1. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 24 4.5 Simulación 2. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 25 4.6 Simulación 2. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 26 4.7 Simulación 2. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 26 4.8 Simulación 2. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 27 4.9 Simulación 3. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 28 4.10 Simulación 3. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 29 4.11 Simulación 3. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 29 4.12 Simulación 3. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 30 4.13 Simulación 4. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 31 4.14 Simulación 4. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 32 4.15 Simulación 4. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 32 119 120 Índice de Figuras 4.16 Simulación 4. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 33 4.17 Simulación 5. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 35 4.18 Simulación 5. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 36 4.19 Simulación 5. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 36 4.20 Simulación 5. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 37 4.21 Simulación 6. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 38 4.22 Simulación 6. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 39 4.23 Simulación 6. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 39 4.24 Simulación 6. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 40 4.25 Simulación 7. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 41 4.26 Simulación 7. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 42 4.27 Simulación 7. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 42 4.28 Simulación 7. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 43 4.29 Simulación 8. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 44 4.30 Simulación 8. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 45 4.31 Simulación 8. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 45 4.32 Simulación 8. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 46 4.33 Simulación 9. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 47 4.34 Simulación 9. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 48 4.35 Simulación 9. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 48 4.36 Simulación 9. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 49 4.37 Simulación 10. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 50 4.38 Simulación 10. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 51 4.39 Simulación 10. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 51 4.40 Simulación 10. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 52 4.41 Simulación 11. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 53 4.42 Simulación 11. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 54 4.43 Simulación 11. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 54 Índice de Figuras 121 4.44 Simulación 11. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 55 4.45 Simulación 12. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 56 4.46 Simulación 12. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 57 4.47 Simulación 12. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 57 4.48 Simulación 12. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 58 4.49 Simulación 13. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 59 4.50 Simulación 13. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 60 4.51 Simulación 13. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 60 4.52 Simulación 13. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 61 4.53 Simulación 14. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 62 4.54 Simulación 14. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 63 4.55 Simulación 14. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 63 4.56 Simulación 14. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 64 4.57 Simulación 15. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 65 4.58 Simulación 15. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 66 4.59 Simulación 15. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 66 4.60 Simulación 15. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 67 4.61 Simulación 16. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 68 4.62 Simulación 16. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 69 4.63 Simulación 16. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 69 4.64 Simulación 16. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 70 4.65 Simulación 17. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 71 4.66 Simulación 17. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 72 4.67 Simulación 17. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 72 4.68 Simulación 17. Media de la evolución del coste del controlador durante las iteraciones del algoritmo MI-LXPM durante una de las simulaciones 73 4.69 Simulación 18. De arriba a abajo. Longitud media de la cola, media de servidores encendidos (azul) + media servidores minimos estimados (rojo), media potencia total consumida (W), media de servidores inactivos (idle) 74 4.70 Simulación 18. De arriba a abajo. Coste total de la solución encontrada en la optimización, esfuerzo de control para cambiar la temperatura del CRAC, esfuerzo de control para encender/apagar servidores 75 4.71 Simulación 18. Evolución de la temperatura de los 25 servidores durante una de las simulaciones 75