Implementación de un simulador de rendimiento, consumo y coste para Centros de Datos integrados en un Smart Grid

Universidad Complutense de Madrid Facultad de Informática Implementación de un simulador de rendimiento, consumo y coste para Centros de Datos integrados en un Smart Grid Alumnos Fernando Baraibar López Roberto Montero Cobo de Guzmán Directores de proyecto José Luis Ayala Rodrigo Marina Zapater Sancho Trabajo de Fin de Grado Ingeniería de Computadores Junio de 2017 2 Índice general Palabras clave 5 Resumen 7 1. Introducción 9 1.1. Antecedentes .................................... 10 1.2. Objetivo....................................... 11 1.3. Plandetrabajo ................................... 11 2. Visión general 15 2.1. ElformalismoDEVS................................ 15 2.1.1. ModeloAtómico.............................. 15 2.1.2. ModeloAcoplado.............................. 17 2.1.3. Simulación de modelos DEVS . . . . . . . . . . . . . . . . . . . . . . . 19 2.2. Construcción de modelos de data center . . . . . . . . . . . . . . . . . . . . . . 20 2.2.1. Introducción ................................ 20 2.2.2. Componentes de un data center . . . . . . . . . . . . . . . . . . . . . . 20 2.2.3. DC-Simulator................................ 22 2.2.4. Implementación de los modelos de consumo en DC-Sim . . . . . . . . . 23 2.2.5. DC-Simulator en xDEVS . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3. Estructura y comportamiento 27 3.1. Estructura...................................... 27 3.1.1. SFIDE: modelo acoplado raíz . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.2. Room.................................... 29 3.1.3. Cooling................................... 36 3.2. Comportamiento .................................. 37 3.2.1. JobsGenerator ............................... 38 3.2.2. Allocator .................................. 38 3.2.3. IRC..................................... 38 3.2.4. Rack .................................... 39 3.2.5. Server.................................... 39 3.2.6. Weather................................... 40 3 4ÍNDICE GENERAL 3.2.7. Chiller ................................... 40 3.2.8. Pump.................................... 40 3.2.9. EnergyCalculator ............................. 40 4. Resultados, conclusiones y futuros desarrollos 43 4.1. Escenarios...................................... 43 4.2. Resultados...................................... 43 4.2.1. Resultados escenario pequeño . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2. Resultados escenario mediano . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.3. Análisis del tiempo de ejecución . . . . . . . . . . . . . . . . . . . . . . 50 4.3. Otrasejecuciones.................................. 51 4.4. Conclusiones .................................... 51 4.5. Futurosdesarrollos ................................. 52 Bibliografía 55 Agradecimientos 57 Autorización de difusión 59 Palabras clave Palabras clave en Español Modelado y simulación Sistemas de eventos discretos Formalismo DEVS Sistemas de ventilación manual mecánica Centro de Proceso de Datos Eficiencia energética de centros de proceso de datos Keywords in English Modeling and simulation Discrete events system DEVS formalism Freecooling Data Center Energy Efficiency in Data Centers 5 6Palabras clave Resumen Resumen en Español Actualmente uno de los mayores costes de un Centro de Proceso de Datos es el consumo eléctrico, especialmente el generado para el funcionamiento de los sistemas de refrigeración. Los simuladores constituyen una herramienta imprescindible para optimizar su funcionamiento de la forma más eficiente posible. A su vez, los simuladores deben ejecutarse en tiempos razonables, además de permitir su ejecución con distintas configuraciones de los sistemas cuyo comportamiento se quiere simular. Este proyecto consiste en la elaboración y desarrollo de un modelo de consumo de un Data Center utilizando las ecuaciones descritas en los artículos "Dynamic Workload and Cooling Management in High-Efficiency Data Centers" y"Leakage-Aware Cooling Management for Improving Server Energy Efficiency", reseñados en la bibliografía [1] y [2], empleadas anteriormente en el simulador DC-Sim, generando una infraestructura base para futuros desarrollos. El nuevo modelo, basado en el formalismo DEVS, es fácilmente escalable y permite la ampliación con nuevas funcionalidades, además de permitir la implementación de cualquier topología y tamaño de Data Center, con diferentes cargas de trabajo. Summary in English Currently, one of the highest costs of a Data Processing Center comes from electrical consumption, especially the one produced to allow proper functioning of the cooling systems. Simulators are an essential tool to optimize the performance of the cooling systems in the most efficient way possible. Thus, simulators must be executed within reasonable times, and their execution must be compatible with different settings of those systems whose behavior is to be simulated. The present project deals with the creation and development of a consumption model for a Data Center using the equations described in the following articles: "Dynamic Workload and Cooling Management in High-Efficiency Data Centers.and "Leakage-Aware Cooling Management for Improving Server Energy Efficiency ", referenced in the bibliography, [1] and [2]. These equations were previously used in the DC-Sim simulator, generating a basic infrastructure for future developments. The new model, based on the DEVS formalism, is easily scalable and allows expansion with new functionalities, besides allowing implementation of any topology and size of a Data Center, 7 8Resumen with different workloads. Capítulo 1 Introducción La rápida evolución de la tecnología ha permitido un desarrollo de forma exponencial de los sistemas de información. La posibilidad de instalar varios equipos más potentes en el espacio que hace unos años ocupaba uno sólo ha generado un considerable incremento en la potencia necesaria para el funcionamiento del conjunto. El aumento de la densidad de equipos en las instalaciones hace que se genere más calor y de forma más concentrada, por lo que ha sido necesario desarrollar sistemas de refrigeración más sofisticados y eficientes, con el fin de evitar sobrecargas térmicas. Es por todo esto que los Data Center cada vez consumen más energía. Mientras que el coste de los equipos se ha reducido, el de la electricidad y los sistemas de refrigeración se ha incrementado considerablemente, dando lugar al extremo de que es fácil que llegue a resultar más caro mantener en funcionamiento un equipo que el propio equipo. Estas circunstancias hacen imprescindible un profundo estudio a la hora de afrontar la instalación de un Data Center. El coste energético puede variar considerablemente dependiendo, por ejemplo, de su localización geográfica, en cuanto que la temperatura exterior influirá en el gasto asociado al proceso de refrigeración. También su topología, las diferentes cargas de trabajo o los distintos tipos de servidores instalados afectará directamente sobre la factura eléctrica. Para poder tomar decisiones sobre la ubicación y características de un Data Center resulta de extrema utilidad la utilización de sistemas que simulen su comportamiento con las diferentes condiciones que puedan afectar a su consumo y eficiencia. Las simulaciones permiten abstraer la complejidad de un sistema para generar una herramienta que permita comprender con mayor facilidad la evolución de éste en el tiempo. Introduction The fast evolution of technology has allowed an exponential development of information systems. The possibility to install several and more powerful machines in the same space which, a few years ago, was taken up by just one equipment, has caused a considerable increase in the power needed to operate the whole set. Increasing the equipment’s density in the facilities causes more heat, and enhances its concentration. Therefore, it has been necessary to develop more sophisticated and efficient cooling 9 16 CAPÍTULO 2. VISIÓN GENERAL Una función de transición interna, que determina el estado al que debe pasar el sistema al finalizar el tiempo determinado por la función de avance de tiempo. Una función de transición externa, que determina el cambio a otro estado cuando se recibe una entrada. Es función del estado actual, del puerto por el que se recibe la entrada, el valor recibido y el tiempo transcurrido en el estado actual. Una función de transición confluyente, que permite especificar cuál es el nuevo estado cuando se produce la confluencia de una transición interna y una externa. Una función de salida, que genera una salida inmediatamente antes de producirse una transición interna. Un modelo DEVS atómico se especifica como: M=hXM, S, YM, δint, δext, δcon, λ, tai(2.1) donde: XM: Conjunto de eventos de entrada, formados por pares puerto-valor: XM={(p, v)|p∈InP orts, v ∈Xp}(2.2) S: Conjunto de estados secuenciales. YM: Conjunto de eventos de salida, formado por pares puerto-valor: YM={(p, v)|p∈OutP orts, v ∈Yp}(2.3) δint :S→S, función de transición interna. δext :Q×Xb M→S, función de transición externa, con Q={(s, e)|s∈S, e ∈[0, ta(s)]}(2.4) Cada elemento del conjunto Qestá formado por dos valores: (s,e), donde ses un elemento del conjunto Syees un número real positivo: el tiempo transcurrido desde la anterior transición del estado. δcon :Q×Xb M→S, función de transición confluyente λ:S→Yb, función de salida que dependerá de la duración del estado. ta :S→R+ 0,función de avance de tiempo. Al definir la función de transición externa, Xb Mrepresenta una "bolsa" de parejas (puerto,evento), que contempla el hecho de que pueden llegar múltiples eventos simultáneamente a un mismo puerto, o a diferentes puertos. 2.1. EL FORMALISMO DEVS 17 De igual manera, la función de salida λgenera una "bolsa" de eventos de salida, Yb. La función de transición confluyente, δcon, tiene como finalidad definir un nuevo estado cuando en un mismo instante se recibe una "bolsa" de eventos de entrada y está planificada una transición interna de estado. Esta función permite determinar cuál es el nuevo estado cuando se produce la confluencia de una transición interna y otra externa. En cualquier momento, el sistema se encuentra en un estado s. Si no se produce ningún evento de entrada, el sistema permanecerá en dicho estado sdurante un tiempo ta(s). Si ta(s)=0, el estado se considera de transición, en el que no es posible que suceda ningún evento externo. Si, por el contrario, ta(s) = ∞, el sistema permanecerá en tal estado, denominado pasivo, hasta que reciba algún evento externo. Figura 2.1.1.a: Diagrama de tiempo del modelo atómico Cuando el tiempo transcurrido en un estado S supera a ta(s), el sistema genera un evento de salida λ(s), pasando al estado s0=δint(s), el estado de transición interna y sabemos que no se ha producido ningún evento externo durante el tiempo permanecido en el estado s. Si antes de producirse la transición interna ocurriera un evento externo con valor x, mientras el sistema se encuentra en el estado (s, e), siendo e≤ta(s), el sistema pasaría al estado δext(s, e, x), pero sin producirse ningún evento de salida. 2.1.2. Modelo Acoplado Un modelo acoplado está constituido por un conjunto de modelos atómicos y/o acoplados, cuyas entradas y salidas se encuentran interconectadas entre ellos y con el exterior del sistema. Un modelo acoplado N se define: N=hX, Y, D, {Md|d∈D}, EIC, EOC, ICi(2.5) donde: X: Conjunto de eventos de entrada. 18 CAPÍTULO 2. VISIÓN GENERAL D: Conjunto de los nombres de los componentes (atómicos o acoplados). Y: Conjunto de eventos de salida. Md: modelo DEVS para cada d∈D. EIC : conjunto de conexiones de entrada externas. EOC : conjunto de conexiones de salida externas IC : conjunto de conexiones internas. Figura 2.1.2.a: Modelo acoplado DEVS En el ejemplo se muestra el modelo acoplado N, con tres componentes M1, M2 y M3, que pueden ser a su vez atómicos o acoplados, y sus interconexiones mediante los correspondientes puertos de entrada y salida, así como las conexiones externas de entrada (EIC) y de salida (EOC). La definición formal del modelo representado en la figura 2.1.2.a sería: N=hX, Y, D, {Md|d∈D}, EIC, EOC, ICi(2.6) donde: X= Conjunto de eventos de entrada. Y= Conjunto de eventos de salida. D={M1, M2, M3}. Md={MM1, MM2, MM3}. EIC ={(N, in)→(M1, in)}. EOC ={(M3, out)→(N, out)}. IC ={(M1, out)→(M2, in),(M2, out)→(M3, in)}. 2.1. EL FORMALISMO DEVS 19 2.1.3. Simulación de modelos DEVS La formalización DEVS permite la simulación de modelos muy complejos de una manera sencilla y eficiente. La estructura del simulador se obtiene a partir del modelo definido, de la siguiente forma: A cada modelo atómico DEVS se le asocia un algoritmo denominado Simulator, que realiza la simulación del modelo DEVS atómico. A cada modelo acoplado DEVS se le asocia un algoritmo denominado Coordinator, que realiza la simulación del modelo DEVS acoplado. En la raíz de la jerarquía del simulador se sitúa el algoritmo Root Coordinator. Figura 2.1.3.a: Estructura del simulador DEVS. El algoritmo de simulación es el siguiente: 1. El Coordinator solicita que cada Simulator facilite la hora de su siguiente evento, seleccionando el que presente la menor. 2. Se actualiza el tiempo de simulación thasta el tiempo de transición de su δint. 3. Se ejecutan las funciones λyδint correspondientes al componente atómico asociado al Simulator seleccionado. 4. Tras la ejecución de la función λse propagan las salidas generadas hacia los elementos conectados, ejecutándose las funciones δext de éstos. 5. Se vuelve a ejecutar el paso 1. 20 CAPÍTULO 2. VISIÓN GENERAL 2.2. Construcción de modelos de data center 2.2.1. Introducción Un centro de procesamiento de datos es una instalación formada por múltiples servidores cuyo objetivo es el procesamiento, almacenamiento y acceso de datos. La propia definición de data center abarca tanto a los pequeños armarios de una oficina como a las grandes granjas de servidores de empresas como Google. 2.2.2. Componentes de un data center Los datacenters están conformados por un sistema de refrigeración, un sistema distribuido de servidores y, opcionalmente, un sistema de alimentación auxiliar. Sistemas de refrigeración: Un datacenter, al estar constituido por servidores, genera grandes cantidades de calor que, con los medios integrados de disipación de calor no son capaces de extraerlo, acumulándose en la estancia del CPD y afectando negativamente al rendimiento de las CPUs. Por esta razón se requiere un sistema adjunto que sea externo a los servidores y que retire el aire caliente que dichos servidores generan. Existen 2 tipos de sistemas de refrigeración externos a los servidores: •Refrigeración In-Rack: Se trata de un sistema de refrigeración “close-coupled", que acerca la fuente fría (el agua) a la fuente de calor (los servidores), que es altamente eficiente en términos de consumo energético. Para cada rack o agrupación de racks se le asigna una toma de entrada de agua fría, que se calentará a partir del aire caliente generado por los servidores del Rack, dando lugar a agua caliente que se irá de vuelta por el mismo circuito, como se muestra en la figura 2.2.2.a. Figura 2.2.2.a:Sistema de refrigeración In-Rack[1] 2.2. CONSTRUCCIÓN DE MODELOS DE DATA CENTER 21 Los sistemas de refrigeración In-Rack requieren de 3 componentes externos a los Rack. 1. Bomba de agua: Se encarga de mover el agua caliente y el agua fría a través del circuito de refrigeración. 2. Enfriador: El enfriador se encarga de enfriar el agua del circuito siempre que el intercambiador de calor no sea suficiente para enfriar el agua a la temperatura preestablecida recibida de la refrigeración de los servidores. 3. Intercambiador de calor: Un intercambiador de calor es un sistema que permite que dos fluidos intercambien calor sin necesidad de mezclarse. Está formado por una cámara que contiene uno de los fluidos y una bobina dentro de la cámara con el fluido a mayor temperatura. En el MGHPCC el fluido frío (a la temperatura del exterior) viene de la torre de refrigeración y el agua caliente viene de la refrigeración de la sala de servidores. 4. Torre de refrigeración. La función de la torre de refrigeración es enfriar el agua procedente del intercambiador de calor, enviándola de vuelta a éste. •Refrigeración mediante CRAC (Computer Room Air Conditioning): A diferencia de la refrigeración In-Rack, no se basa en la aproximación del elemento refrigerante a la fuente de calor, sino que dispone de un intercambiador de calor a través del cual circula el agua fría procedente de los componentes externos (bomba, enfriador, intercambiador de calor y torre de refrigeración), que absorbe el calor generado por los servidores, enfriando el aire y haciéndolo circular de vuelta a la zona en que se encuentran los racks. Este sistema es mucho menos eficiente que la refrigeración In-Rack. Figura 2.2.2.b. Refrigeración mediante CRAC Sistemas de TIC: Se encargan de realizar el trabajo de cómputo del CPD. Sistemas de alimentación: Un CPD debe estar disponible en torno al 99 % del tiempo, por 22 CAPÍTULO 2. VISIÓN GENERAL ello exigen fuentes de alimentación auxiliares, para que en caso de que falle la Red eléctrica el CPD no se apague. Suelen estar conformados por baterías y/o generadores eléctricos de diesel o gasolina. 2.2.3. DC-Simulator DC-Sim nace como un proyecto para la simulación del consumo del MGHPCC (Massachusetts green high performance computing center) con el objetivo de ser una herramienta para la investigación en técnicas de reducción del consumo en los centros de procesado de datos [1]. La finalidad de DC-Sim es conseguir los datos de consumo de un centro de procesado de datos a partir de la topología de dicho CPD, una serie de tareas y los valores de la temperatura ambiental. Existen dos posibilidades de funcionamiento en DC-Sim: Funcionamiento estático: Como su propio nombre indica, el funcionamiento estático sólo obtiene el consumo para un momento determinado. Se comporta como el funcionamiento dinámico para una única iteración. Figura 2.2.3.a. Funcionamiento estático de DC-Sim Funcionamiento dinámico: La simulación dinámica supone que el sistema evoluciona en función del tiempo, es decir, la temperatura a la que se ejecuta la simulación varía en función de un archivo de temperaturas y se van agregando y terminando tareas en los servidores a lo largo de dicha ejecución. Figura 2.2.3.b. Funcionamiento dinámico de DC-Sim. Las fases de ambos tipos de simulaciones se resumen en: 2.2. CONSTRUCCIÓN DE MODELOS DE DATA CENTER 23 Configuración: A partir de los datos del archivo de topología se construyen los modelos de los sistemas con los que trabaja el simulador, es decir la refrigeración y la sala de servidores; además se configuran algunos parámetros como los tiempos de inicio y de llegada de los trabajos. Asignación de tareas: Esta tarea sólo está disponible en modo dinámico y se encarga de asignar las tareas de un archivo a un servidor. La información de las tareas en el archivo es: su servidor objetivo, el tiempo durante el cual sé ejecutarán y cómo modifican el consumo dinámico de las CPUs y las memorias. Política de refrigeración: Esta etapa se encarga de modificar algunos parámetros de refrigeración cómo la velocidad de los ventiladores o la temperatura del aire que llega a los racks, según sea la política de enfriamiento empleada. Cálculo de consumo de energía: Esta fase ejecuta la lógica relacionada con el consumo y devuelve los valores de potencia y energía para un momento determinado. 2.2.4. Implementación de los modelos de consumo en DC-Sim El simulador actual dispone de un modelo para cada uno de los elementos de consumo eléctrico de un data center refrigerado por un sistema de refrigeración In-Rack: El modelo de consumo de data center considera la contribución de los k1IRCs, los k2servidores y el sistema de refrigeración (enfriador, bomba de agua y torre de refrigeración). La ecuación del modelo de datacenter sería: PDataCenter = k2 X n=0 Pserver,n + k1 X n=0 PIRC,n +Pchiller +Ppump +PCoolingT ower (2.7) Servidor: El modelo de consumo de un servidor está definido por la suma de potencias: Pserver =Pidle +Pcpu,dyn +Pleakeage +Pfan +Pmem,dyn (2.8) Siendo Pidle la potencia correspondiente a la cpu, el disco y las memorias en idle; Pcpu,dyn y Pmem,dyn los incrementos de consumo de potencia de la CPU y la memoria, respectivamente, al realizar una tarea; Pleakeage será el consumo extra de potencia derivado del incremento de temperatura; y el Pfan vendrá de la potencia usada por el ventilador. Cabe recordar que estos valores variarán en función de las tareas y el servidor empleados. Refrigerador In-Rack (IRC): El consumo de potencia del IRC es función cúbica con relación al flujo de aire que recibe de los servidores, ya que debe extraer el calor de dicho flujo de aire mediante la ventilación del IRC y la circulación de agua fría. La ecuación del consumo de potencia del IRC es: PIRC =α3∗airflow3+α2∗airflow2+α1∗airflow +α0(2.9) Siendo airflow la suma del flujo de aire de los servidores refrigerados por el IRC correspondiente, y α3,α2,α1,α0coeficientes de la ecuación y específicos del IRC en cuestión. 24 CAPÍTULO 2. VISIÓN GENERAL Enfriador, torre de refrigeración y bomba de agua: El modelo de consumo del sistema de refrigeración tendrá en cuenta la temperatura exterior. Si ésta es suficientemente baja se aplica el modelo de consumo freecooling, en el que Pchiller = 0; el PCoolingT ower se obtiene de una lookup table (LUT) creada a partir de las datasheets facilitadas por el fabricante. Si no se pudiese aplicar una política de freecooling, Pchiller vendrá dado por las siguiente ecuación: Pchiller =Qevap COPchiller (2.10) siendo Qevap el sumatorio del calor generado por los servidores enfriados por cada IRC. COPchiller es el coeficiente de rendimiento del enfriador: COPchiller =Tevap T cond −Tevap (2.11) donde Tevap es la temperatura del agua en el evaporador y Tcond la temperatura en el condensador. Finalmente, Ppump es proporcional al flujo de agua del IRC y al cambio de presión e inversamente proporcional a la eficiencia de la bomba: Ppump =fIRCwater ∗∆P pump (2.12) 2.2.5. DC-Simulator en xDEVS El objetivo de trasladar DC-Sim a SFIDE implica la formalización de un modelo en DEVS a partir del existente, el cual es ad-hoc. Las ventajas de esta reformalización son: 1. Facilidad de comunicación con otros sistemas DEVS. 2. Sustancial mejora de la gestión del tiempo para los eventos de simulación. 3. Posibilidad de paralelización de los eventos, con la consecuente reducción del tiempo de ejecución en topologías con excesiva carga de trabajo. En el nuevo diseño para DEVS los elementos de consumo de DC-Sim han sido sustituidos por componentes de DEVS. Cada nuevo componente dispone de puertos para comunicar la información que se intercambiaban en DC-Sim. La figura 2.2.5.1 representa un boceto de la estructura en DEVS. 2.2. CONSTRUCCIÓN DE MODELOS DE DATA CENTER 25 Figura 2.2.5.1: Estructura DEVS 32 CAPÍTULO 3. ESTRUCTURA Y COMPORTAMIENTO Por el puerto de entrada “iWaterTemp” recibe la temperatura del agua procedente del componente Cooling que servirá para la refrigeración. Procesando los datos recibidos, genera las siguientes salidas: A través del puerto “oIRCGallons” transmite el flujo de agua necesario para la refrigeración. A través del puerto “oIRCHotWater” transmite la temperatura del agua de retorno a Cooling. A través del puerto “oIRCPower” transmite la potencia consumida por el IRC. A través del puerto “oIRCAvgTempCpu” transmite la temperatura media de las CPU’s. A través del puerto “oIRCMaxTempCpu” transmite la temperatura máxima de las alcanzadas en las CPU’s. Rack: El componente atómico Rack tiene dos funciones. Por una parte, recibe los trabajos a ejecutar en cada uno de los Server alojados en él, transmitiéndoselos a través de los puertos de salida correspondientes. Por otra, recibe los datos generados por cada uno de los Server para generar las salidas que transmitirá al IRC. Figura 3.1.2.3: Modelo atómico Rack. A través del puerto de entrada “iJob” recibe los trabajos procedentes del componente IRC y los transmite a través del puerto de salida “oJob” correspondiente al server al que está 3.1. ESTRUCTURA 33 asignado. Este puerto de salida es realmente un "map"de puertos, existiendo uno por cada Server que se encuentra alojado en cada Rack. Están configurados seis "maps"de puertos de entrada para recibir de cada uno de los Server los datos generados por éstos: A través del puerto “iServersPowerIT” recibe la potencia consumida por las CPU’s, memoria y disco del Server correspondiente. A través del puerto “iServersPowerFS” recibe la potencia consumida por sus ventiladores. A través del puerto “iServersAirflow” recibe el flujo de aire generado por sus ventiladores. A través del puerto “iServersTempOut” recibe la temperatura del aire de cada servidor. A través del puerto “iServersAvgTempCpu” recibe la temperatura media de las cpus contenidas en el servidor. A través del puerto “iServersMaxTempCpu” recibe la temperatura máxima alcanzada por alguna de las cpus contenidas en el servidor. Para transmitir los datos generados a partir de la información recibida de los servidores dispone de seis puertos de salida: A través del puerto “oRackPowerIT” transmite la potencia dinámica, de memoria y de disco consumida por los Server. A través del puerto “oRackPowerFS” transmite la suma de potencias consumidas por los ventiladores del conjunto de servidores. A través del puerto “oRackAirflow” transmite el flujo de aire generado por los ventiladores de todos los servidores del Rack. A través del puerto “oRackTempOut” transmite la temperatura del aire. A través del puerto “oRackAvgTempCpu” transmite la temperatura media de todas las cpus. A través del puerto “oRackMaxTempCpu” transmite la temperatura máxima alcanzada en las cpus. Server: El componente atómico Server es el encargado de calcular la potencia consumida por los elementos de proceso, la memoria, el disco y los ventiladores, así como el flujo de aire y su temperatura de salida y las temperaturas máximas y medias de las cpus. Cada componente Rack se comunica con SServer. 34 CAPÍTULO 3. ESTRUCTURA Y COMPORTAMIENTO Figura 3.1.2.4: Modelo atómico Server. A través del puerto de entrada “iJob” recibe los trabajos procedentes componente Rack, calculando en función de éstos los parámetros que transmitirá de nuevo a Rack a través de los puertos de salida: El puerto “oServerPowerIT” transmite la potencia dinámica, de memoria y de disco consumida por el servidor. El puerto “oServerPowerFS” transmite la potencia consumida por los ventiladores. El puerto “oServerAirflow” transmite el flujo de aire generado por los ventiladores. El puerto “oServerTempOut” transmite la temperatura del aire expulsado por el servidor. El puerto “oServerAvgTempCpu” transmite la temperatura media alcanzada por las cpus que contiene el servidor. El puerto “oServerMaxTempCpu” transmite la máxima temperatura alcanzada por alguna de las cpus. En la inicialización de Server se modifica su estado y al ejecutarse λlos valores de inicialización se colocan en los puertos correspondientes para su transmisión al componente Rack. Como refleja la figura 3.1.2.1, el modelo acoplado Room contiene dos conexiones de entrada externa (EIC): A través del puerto “iJob” se reciben los jobs procedentes de “Jobs Generator” con destino a“Allocator”. A través del puerto “iWaterTemp” se recibe la temperatura exterior, procedente de “Cooling” con destino a “IRC”. Las conexiones de salida externa (EOC) son siete. Dos puertos conectan con el componente Cooling: 3.1. ESTRUCTURA 35 El puerto “oIRCGallons” se emplea para la transmisión de la cantidad de agua necesaria para la refrigeración. A través del puerto “oIRCHotWater” se transmite la temperatura del agua que circula a través del IRC. Cinco puertos conectan con el componente Energy Calculator: A través del puerto “oIRCPower” se transmite la potencia consumida por el IRC. A través del puerto “oIRCFSPower” se transmite la suma de las potencias consumidas por los ventiladores de todos los Server refrigerados a través del IRC. A través del puerto “oIRCITPower” se transmite la suma de las potencias consumidas por los Server. A través del puerto “oIRCMaxTempCpu” se transmite la máxima temperatura alcanzada por alguno de los Server. A través del puerto “oIRCAvgTempCpu” se transmite la temperatura media alcanzada en los Server del correspondiente IRC. Para conectar los diferentes componentes,consta de las siguientes conexiones internas IC: Allocator oJob →iJob IRC IRC oJob →iJob Rack Rack oJob →iJob Server Server oServerPowerIT →iServersPowerIT Rack oServerPowerFS →iServersPowerFS oServerAirflow →iServersAirflow oServerTempOut →iServersTempOut oServerAvgTempCpu →iServersAvgTempCpu oServerMaxTempCpu →iServersMaxTempCpu Rack oRackPowerIT →iRacksPowerIT IRC oRackPowerFS →iRacksPowerFS oRackAirflow →iRacksAirflow oRackTempOut →iRacksTempOut oRackAvgTempCpu →iRacksAvgTempCpu oRackMaxTempCpu →iRacksMaxTempCpu Cuadro 3.2: Conexiones internas de Room 36 CAPÍTULO 3. ESTRUCTURA Y COMPORTAMIENTO 3.1.3. Cooling Figura 3.1.3.1: Modelo acoplado Cooling. La figura 3.1.3.1 muestra el modelo acoplado Cooling, que está formado por los siguientes componentes atómicos: Chiller: Tiene la función de calcular el consumo de potencia del sistema de enfriamiento del Data Center a partir de los datos recibidos del componente Room y la temperatura exterior suministrada por el componente Weather. Dispone de los siguientes puertos: A través del puerto “iWeatherTemp” recibe la temperatura exterior. A través de los puertos “iIRCHotWaterTemp” e“iIRCGallons” recibe la temperatura y flujo de agua de cada IRC que es necesario refrigerar. A través del puerto “oColdWaterTemp” transmite la temperatura del agua que sirve el Chiller. A través del puerto “oWeatherTemp” transmite a Energy Calculator la temperatura exterior para generar el informe de la simulación. 3.2. COMPORTAMIENTO 37 A través de los puertos “oChillerPower” y“oTowerPower” transmite a Energy Calculator la potencia consumida por el enfriador y la torre de refrigeración, respectivamente. Cuando se inicializa se cambia de estado y se ejecuta λ, que coloca en el puerto “oColdWaterTemp” la temperatura del agua fría para ser utilizada por el componente IRC. Pump: A partir del flujo de agua que es necesario hacer circular para la refrigeración, recibido a través del puerto “iIRCGallons”, calcula la potencia consumida por la bomba, transmitiendo el dato a Energy Calculator a través del puerto “oPumpPower” Como refleja la figura 3.1.3.1, el modelo acoplado Cooling presenta tres conexiones de entrada externa (EIC): A través del puerto “iWeatherTemp” recibe la temperatura exterior desde el componente Weather para ser utilizado por Chiller. A través del puerto “iIRCHotWaterTemp”, conectado con Chiller, recibe la temperatura del agua de cada IRC. A través del puerto “iIRCGallons” recibe el fujo de agua de cada IRC, que es transmitido tanto a Chiller como a Pump. Tiene una conexión de salida externa (EOC) que conecta con el componente Room,“oColdWaterTemp”, para transmitir la temperatura del agua servida por Chiller, y cuatro que conectan con Energy Calculator: A través del puerto “oWeatherTemp” transmite la temperatura exterior. A través del puerto “oTowerPower” transmite la potencia consumida por la torre de refrigeración. A través del puerto “oChillerPower” transmite la potencia consumida por el enfriador. A través del puerto “oPumpPower” transmite la potencia consumida por la bomba. Entre los componentes atómicos del acoplado Cooling no existe ninguna conexión, por lo tanto éste no tiene ninguna conexión interna (IC=∅). 3.2. Comportamiento El comportamiento de los componentes atómicos está controlado por las funciones: ·δint, función de transición interna. ·δext, función de transición externa. ·λ, función de salida. 38 CAPÍTULO 3. ESTRUCTURA Y COMPORTAMIENTO ·δcon, función de transición confluyente. En todos los componentes atómicos, esta función establece que se ejecute en primer lugar la función δint y posteriormente δext con e=0, cuando se produzca la confluencia de una transición interna con una externa. ·ta, función de avance de tiempo, que devuelve siempre el valor de σ. 3.2.1. Jobs Generator Función de transición interna: Lee del fichero de joblogger los datos del siguiente job a ejecutar y cambia el estado durante el tiempo que debe que transcurrir antes de transmitir el job leído. Función de transición externa:No está implementado ningún comportamiento porque no se ha contemplado que reciba nada. Función de salida: Coloca el job en el puerto “oOut" para ser leído por el componente Allocator. 3.2.2. Allocator Función de transición interna: Inicializa a "0" el job actual y cambia el estado a "passive". Función de transición externa: Lee del puerto “iJob" el job a ejecutar y cambia el estado a “active" con ta=0.0. Función de salida: Coloca el job en el puerto de salida correspondiente al IRC al que está asignado el job. 3.2.3. IRC Función de transición interna: Inicializa a 0.0 todas las variables y cambia el estado a "passive". Función de transición externa: Lee del puerto “iJob" el job a ejecutar y cambia el estado a “active" con ta=0.0. Lee todos los puertos de entrada a través de los cuales recibe los datos procedentes de los dos Racks, así como el puerto por el que recibe la temperatura del agua, procedente de Chiller. Cuando dispone de todos los datos cambia de estado a “active" con ta=0.0. Función de salida: Coloca el job en el puerto de salida correspondiente al Rack al que está asignado el job. Coloca los datos generados a partir de las entradas en los puertos de salida correspondientes para ser transmitidos a Cooling yEnergy Calculator. El consumo de potencia del IRC es función del flujo de aire que recibe de los servidores, ya que debe extraer el calor de dicho flujo de aire mediante la ventilación del IRC y la circulación del agua fría. El cálculo se realiza mediante la ecuación: PIRC =α3∗airflow3+α2∗airflow2+α1∗airflow +α0(3.1) donde: ·airflow es la suma del flujo de aire de los servidores refrigerados por el IRC. 3.2. COMPORTAMIENTO 39 ·α0,α1,α2yα3los coeficientes de regresión específicos del IRC correspondiente. En este caso: 198.9612, -0.0317, 3,0196 ∗10−5y1,5658 ∗10−8, respectivamente. 3.2.4. Rack Función de transición interna: Inicializa a 0.0 todas las variables y cambia el estado a "passive". Función de transición externa: Lee del puerto “iJob" el job a ejecutar y cambia el estado a“active" con ta=0.0. Lee todos los puertos de entrada a través de los cuales recibe los datos procedentes de los Server. Cuando dispone de todos los datos cambia el estado a “active" con ta=0.0. Función de salida: Coloca el job en el puerto de salida correspondiente al Server al que está asignado el job. Coloca los datos generados a partir de las entradas en los puertos de salida correspondientes para ser transmitidos a IRC. 3.2.5. Server Función de transición interna: Inicializa a 0a variable currentJob y cambia el estado a "passive". Función de transición externa: Lee del puerto “iJob" el job a ejecutar y después de realizar los cálculos de consumo energético y temperatura de los distintos componentes (función updateState()), cambia el estado a “active" con ta=0.0. Función de salida: Coloca los datos generados en los puertos de salida correspondientes para ser transmitidos al Rack. El componente Server genera seis salidas: serverPowerIT, que se obtiene mediante la ecuación: serverP owerIT =idleP ower +memP ower +cpuP ower +leakageP ower (3.2) donde memPower ycpuPower son la potencia dinámica de la memoria y cpu, que se obtiene de los atributos del job que se está ejecutando, idlePower es la potencia consumida en reposo yleakagePower es el consumo debido al incremento de la temperatura durante la ejecución de la carga de trabajo: leakageP ower =α0+α1∗TCP U +α2∗T2 CP U (3.3) donde TCP U es la temperatura de la CPU y α0,α1yα2coeficientes de regresión. serverPowerFS, la potencia consumida por el ventilador, que se calcula en función de la velocidad. serverAirflow, el flujo de aire, también en función de la velocidad del ventilador. 40 CAPÍTULO 3. ESTRUCTURA Y COMPORTAMIENTO serverTempOut, la temperatura del aire a la salida del Server, que es directamente proporcional a la temperatura de inlet y a serverPowerIT, e inversamente proporcional al flujo de aire generado (serverAirflow). serverAvgTempCpu, la temperatura media de las CPU’s. La temperatura se calcula en función de la temperatura de inlet, la velocidad del ventilador y la potencia dinámica de la CPU. serverMaxTempCpu, la máxima temperatura alcanzada por una de las CPU’s del Server. 3.2.6. Weather Función de transición interna: Lee del fichero de temperaturas el siguiente registro, si existe, y cambia el estado a “active", si quedan más registros por leer, o a “pasive", si ya ha finalizado. Función de transición externa: No está implementado ningún comportamiento porque no se ha contemplado que reciba nada. Función de salida:Si se ha llegado al final del fichero de temperaturas, coloca en el puerto “oStop" el booleano false para ser leído por Job Generator. En caso contrario, coloca el valor de la temperatura leído en el puerto “oOut" para ser leído por el componente Chiller. 3.2.7. Chiller Función de transición interna: Inicializa todas las variables y cambia el estado a “passive". Función de transición externa: Lee todos los puertos de entrada a través de los cuales recibe los datos procedentes de los IRC, así como el puerto del que recibe la temperatura exterior desde el componente Weather. Cuando dispone de todos los datos cambia el estado a “active" con ta=0.0. Función de salida: Coloca en el puerto “oColdWaterTemp" la temperatura del agua para ser leída por IRC. En los puertos “oChillerPower",“oTowerPower" y“oWeatherTemp", respectivamente, los valores de consumo de Chiller y Tower, así como la temperatura exterior, para ser leídos por Energy Calculator. 3.2.8. Pump Función de transición interna: Inicializa las variables y cambia el estado a “passive". Función de transición externa: Lee el dato de flujo de agua necesario para la refrigeración de cada uno de los IRC y en función de aquél calcula la potencia consumida en el proceso de bombeo, tras lo cual cambia el estado a “active" con ta=0.0. Función de salida: Coloca en el puerto “oPumpPower" el dato de potencia calculado anteriormente. 3.2.9. Energy Calculator Función de transición interna: Inicializa las variables y cambia el estado a “passive". 3.2. COMPORTAMIENTO 41 Función de transición externa: Lee los datos de potencia consumida facilitados por los componentes IRC,Chiller yPump, así como la temperatura externa,y los escribe en el fichero de salida. Función de salida: Al no existir comunicación hacia ningún otro componente no es necesario que esté definida. 48 CAPÍTULO 4. RESULTADOS, CONCLUSIONES Y FUTUROS DESARROLLOS Figura 4.2.2.b: Temperatura exterior (izquierda) y de los servidores (derecha). La temperatura en los servidores está condicionada por la diferente carga de trabajo en cada instante. Al cambiar de tamaño de escenario, lo primero que se observa en la figura 4.2.2.a es un incremento en los consumos de todos los componentes proporcional al incremento del número de servidores. En segundo lugar, teniendo en cuenta que el comportamiento del sistema de refrigeración es igual en ambos escenarios, se puede observar un leve aumento del consumo de cooling, debido principalmente al aumento de los galones de agua requeridos por los IRC y que será bastante más significativo en los escenarios posteriores. Además se sigue observando que los gráficos son iguales en ambos simuladores. Temperatura moderada Figura 4.2.2.c: Consumo por componentes DC-Sim (izquierda) y SFIDE(derecha) en el escenario mediano con temperaturas moderadas. En ambos modelos se obtienen valores iguales para todos los componentes: IT, FS, IRC y Cooling. 4.2. RESULTADOS 49 Figura 4.2.2.d: Temperatura exterior (izquierda) y de los servidores (derecha). La temperatura en los servidores está condicionada por la diferente carga de trabajo en cada instante. El incremento de la temperatura exterior provoca el aumento del consumo de cooling de manera proporcional al producido en el escenario pequeño. La imposibilidad de refrigerar el sistema mediante freecoling en los momentos en que la temperatura exterior es más elevada, hace que el gráfico presente una serie de "picos"de consumo. El mayor número de servidores, además, hace que el flujo de agua necesario para la refrigeración de los IRC sea mayor, incrementando el consumo de la bomba. Temperatura alta Figura 4.2.2.e: Consumo por componentes DC-Sim (izquierda) y SFIDE(derecha) en el escenario mediano con temperaturas altas. En ambos modelos se obtienen valores iguales para todos los componentes: IT, FS, IRC y Cooling. 50 CAPÍTULO 4. RESULTADOS, CONCLUSIONES Y FUTUROS DESARROLLOS Figura 4.2.2.f: Temperatura exterior (izquierda) y de los servidores (derecha). La temperatura en los servidores está condicionada por la diferente carga de trabajo en cada instante. En las figuras 4.2.2.e y 4.2.2.f se observa como el consumo de la refrigeración de los servidores y los ventiladores pueden llegar a superar al consumo de IT, disparando los consumos totales y las temperaturas en momentos de excesiva carga de trabajo en los servidores y en condiciones de alta temperatura exterior. 4.2.3. Análisis del tiempo de ejecución Ambos escenarios se probaron sobra una máquina virtual de Ubuntu 16.04 con 3GB de RAM; el hardware utilizado fue: un Intel Core i5-5200U @ 2.20Ghz, 8 GB de RAM DDR3L y un SSD 128GB. Figura 4.2.3:Tiempos de ejecución en DC-Sim y SFIDE El tiempo de ejecución de ambos simuladores queda reflejado en la figura 4.2.3. Como puede observarse el tiempo de ejecución en SFIDE es mayor que en DC-Sim. El tiempo de ejecución de ambos simuladores escala con el número de trabajos y el número de servidores, pero en SFIDE 4.3. OTRAS EJECUCIONES 51 el hecho de tener que recorrer cada componente atómico en busca del menor sigma penaliza su tiempo de ejecución frente a DC-Sim. Además el uso de una memoria de estado sólido favorece los accesos aleatorios a los nuevos archivos de trabajo en DC-Sim. Se conseguiría una mejora sustancial en el tiempo de ejecución de SFIDE pasando del simulador secuencial actual, a un simulador paralelo que permitiese la "división aproximada"del tiempo de ejecución entre el número de hilos para la búsqueda del menor sigma en el árbol de coordinadores y simuladores, y la ejecución de las funciones de transición. 4.3. Otras ejecuciones Una vez validada la nueva implementación y con el fin de comprobar la flexibilidad y escalabilidad del modelo SFIDE, modificamos la configuración del data center de manera que cada rack tiene nueve servidores, a los que les asignamos una carga de trabajo equivalente a la utilizada en el escenario pequeño. Así, tenemos una configuración con 3 IRC’s, 6 racks y 54 servidores, con un conjunto de 330.447 trabajos. Figura 4.3.a: Consumo por componentes (izquierda) y temperatura de los servidores (derecha). Como puede observarse en la figura 4.3.a, el resultado de la simulación refleja unos datos coherentes con respecto a los obtenidos anteriormente. 4.4. Conclusiones El diseño e implementación del modelo SFIDE, objeto del presente trabajo, confirma la aplicabilidad del formalismo DEVS para el desarrollo de este tipo de aplicaciones. Con los resultados obtenidos se demuestra que la separación entre el modelo y el simulador es posible, permitiendo además una extraordinaria facilidad a la hora de añadir nuevas funciones en futuros desarrollos. El hecho de que el modelo SFIDE sea independiente del simulador puede resultar interesante ya que, si se desea paralelizar los eventos para un tiempo determinado, e incluso el simulador de la aplicación, no es necesario cambiar el modelo. Se puede conseguir de esta manera una importante mejora en el tiempo de ejecución cuando el número de servidores sea muy elevado. 52 CAPÍTULO 4. RESULTADOS, CONCLUSIONES Y FUTUROS DESARROLLOS Para verificar la validez de los resultados obtenidos, se han ejecutado los mismos escenarios en el simulador DC-Sim y en SFIDE, comprobando que aquéllos son iguales para ambos en todas las situaciones. La mayor flexibilidad y escalabilidad de SFIDE le convierte en una herramienta muy útil para la simulación de Data Center de diferentes topologías, con diferentes tipos de servidores e incluso en distintas localizaciones geográficas sin necesidad de realizar costosas adaptaciones. La estructura de comunicación entre los distintos componentes permite la incorporación de nuevos elementos de una manera inmediata. Conclusions The design and implementation of the SFIDE model, focus of the present study, confirms the applicability of the DEVS formalism for the development of this kind of applications. The results obtained show that the division between model and simulator not only is possible, but also leads to an extraordinary simplicity when adding new features in future developments. The fact that the SFIDE model is independent from the simulator might be interesting, since, if the events (and even the application simulator) are to be parallelized for a certain time, it is not necessary to change the model. This way, a significant improvement in the execution time may be achieved, when the number of servers is very high. To verify the validity of the results obtained, the same scenarios have been executed in the DC-Sim simulator and in SFIDE, and the results are the same in both of them and in any kind of situation. SFIDE’s great flexibility and scalability makes it a very useful tool for the Data Center simulation, with different topologies, different kinds of servers and even different geographic locations, and without the need for any expensive adjustments. The communication structure between the different components allows an immediate incorporation of new elements. 4.5. Futuros desarrollos Este proyecto supone la base de nuevos desarrollos para la simulación de rendimiento en centros de datos integrados. En un futuro se crearán nuevos componentes para el simulador como la inclusión de nuevas políticas de refrigeración y/o un nuevo gestor de la temperatura de las CPU’s. Una de las posibles expansiones de este desarrollo sería añadir la posibilidad de emplear una política de minimización de consumo de refrigeración denominada budget heat. Para implementarla sería necesario un nuevo atómico, el cual recibiría por un puerto el sumatorio de los consumos dinámicos que lleguen a los IRC y un puerto del chiller que compruebe si el freecooling es posible con el calor y la temperatura actual. En el momento en que reciba el nuevo consumo referente a cada trabajo debe ejecutar un bucle que consiga la porción del calor que esta extrayendo el Chiller se corresponde con cada IRC. Para saber la temperatura del chiller se debe extender el puerto que envía la temperatura del chiller al IRC para que llegue al nuevo atómico. Una vez hallados estos parámetros hay que probar todas 4.5. FUTUROS DESARROLLOS 53 las posibles configuraciones de ventiladores y temperatura de inlet y marcar aquellas que no den problemas de temperaturas en las CPU’s. Una vez conseguidas las configuraciones validas hay que discriminar aquellas que tenga el menor consumo posible y preservar dichas configuraciones en todos los servidores e IRC’s. En esta política de refrigeración sería interesante la inclusión de un simulador paralelo para DEVS, ya que todos servidores deben variar su estado y sus datos no son dependientes entre sí dando cabida al paralelismo previamente solicitado. Además de la mejora de rendimiento del simulador al recorrer el árbol de coordinadores en un tiempo proporcional al número de hilos de ejecución. El modelo DEVS permitiría también el estudio de la variación de temperaturas. Sabemos que la temperatura de la CPU sigue una exponencial creciente, que afecta al consumo de leakage (Pleak). Actualmente sólo se calcula el estado estacionario, pero añadiendo una transición interna δint en el componente atómico Server se podrían calcular estos transitorios. Otra de las opciones de ampliación de la funcionalidad es: crear un nuevo atómico planificador que, en vez de recibir el objetivo de las tareas desde un archivo de texto, elija el objetivo de los trabajos priorizando a aquel servidor que menos consumo produzca. Para ello sería necesario que todos servidores tengan un puerto que lleve al nuevo planificador, se realice una búsqueda del mínimo consumo y si se cumplen las restricciones enviar la tarea a ese servidor por el método actual. Para facilitar el uso del simulador se podría crear una GUI, que permitiese la monitorización y gestión de los distintos componentes que conforman el data center. 54 CAPÍTULO 4. RESULTADOS, CONCLUSIONES Y FUTUROS DESARROLLOS Bibliografía [1] MARINA ZAPATER, ATA TURK, JOSE M. MOYA, JOSE L. AYALA AND AYSE K. COSKUN, Dynamic Workload and Cooling Management in High-Efficiency Data Centers [2] MARINA ZAPATER, OZAN TUNCER, JOSE L. AYALA, JOSE M. MOYA, KALYAN VAIDYANATHAN, KENNY GROSS,AND AYSE K. COSKUN,Leakage-Aware Cooling Management for Improving Server Energy Efficiency [3] I. PENAS, M. ZAPATER, J.L. RISCO, J.L. AYALA AND AYSE K. COSKUN,Sfide: A simulation infrastructure for Data Centers [4] JOSÉ L. RISCO AND SAURABH MITAL,“xDEVS r20150903" [5] JOSÉ L. RISCO AND SAURABH MITAL,Netcentric System of Systems Engineering with DEVS Unified Process [6] JOSÉ DAMIÁN FERRER QUINTANA,Centro de Proceso de Datos: el cerebro de nuestra sociedad [7] ALFONSO URQUÍA,Modelado de sistemas mediante DEVS 55 56 Bibliografía Agradecimientos A Jose Luis Ayala, por darnos la posibilidad de afrontar el reto que nos ha supuesto la realización de este proyecto. A José Luis Risco, Marina Zapater e Ignacio Penas, por su inestimable ayuda para la su elaboración. 57