source: papers/SMPaT-2012_DCWoRMS/elsarticle-DCWoRMS.tex @ 731

Revision 731, 65.8 KB checked in by ariel, 12 years ago (diff)

abstract i intro update

Line 
1%% This is file `elsarticle-template-1-num.tex',
2%%
3%% Copyright 2009 Elsevier Ltd
4%%
5%% This file is part of the 'Elsarticle Bundle'.
6%% ---------------------------------------------
7%%
8%% It may be distributed under the conditions of the LaTeX Project Public
9%% License, either version 1.2 of this license or (at your option) any
10%% later version.  The latest version of this license is in
11%%    http://www.latex-project.org/lppl.txt
12%% and version 1.2 or later is part of all distributions of LaTeX
13%% version 1999/12/01 or later.
14%%
15%% The list of all files belonging to the 'Elsarticle Bundle' is
16%% given in the file `manifest.txt'.
17%%
18%% Template article for Elsevier's document class `elsarticle'
19%% with numbered style bibliographic references
20%%
21%% $Id: elsarticle-template-1-num.tex 149 2009-10-08 05:01:15Z rishi $
22%% $URL: http://lenova.river-valley.com/svn/elsbst/trunk/elsarticle-template-1-num.tex $
23%%
24\documentclass[preprint,12pt]{elsarticle}
25
26%% Use the option review to obtain double line spacing
27%% \documentclass[preprint,review,12pt]{elsarticle}
28
29%% Use the options 1p,twocolumn; 3p; 3p,twocolumn; 5p; or 5p,twocolumn
30%% for a journal layout:
31%% \documentclass[final,1p,times]{elsarticle}
32%% \documentclass[final,1p,times,twocolumn]{elsarticle}
33%% \documentclass[final,3p,times]{elsarticle}
34%% \documentclass[final,3p,times,twocolumn]{elsarticle}
35%% \documentclass[final,5p,times]{elsarticle}
36%% \documentclass[final,5p,times,twocolumn]{elsarticle}
37
38%% if you use PostScript figures in your article
39%% use the graphics package for simple commands
40%% \usepackage{graphics}
41%% or use the graphicx package for more complicated commands
42%% \usepackage{graphicx}
43%% or use the epsfig package if you prefer to use the old commands
44%% \usepackage{epsfig}
45
46%% The amssymb package provides various useful mathematical symbols
47\usepackage{amssymb}
48\usepackage{multirow}
49%% The amsthm package provides extended theorem environments
50%% \usepackage{amsthm}
51
52%% The lineno packages adds line numbers. Start line numbering with
53%% \begin{linenumbers}, end it with \end{linenumbers}. Or switch it on
54%% for the whole article with \linenumbers after \end{frontmatter}.
55%% \usepackage{lineno}
56
57%% natbib.sty is loaded by default. However, natbib options can be
58%% provided with \biboptions{...} command. Following options are
59%% valid:
60
61%%   round  -  round parentheses are used (default)
62%%   square -  square brackets are used   [option]
63%%   curly  -  curly braces are used      {option}
64%%   angle  -  angle brackets are used    <option>
65%%   semicolon  -  multiple citations separated by semi-colon
66%%   colon  - same as semicolon, an earlier confusion
67%%   comma  -  separated by comma
68%%   numbers-  selects numerical citations
69%%   super  -  numerical citations as superscripts
70%%   sort   -  sorts multiple citations according to order in ref. list
71%%   sort&compress   -  like sort, but also compresses numerical citations
72%%   compress - compresses without sorting
73%%
74%% \biboptions{comma,round}
75
76% \biboptions{}
77
78
79\journal{Simulation Modelling Practice and Theory}
80
81\begin{document}
82
83\begin{frontmatter}
84
85%% Title, authors and addresses
86
87%% use the tnoteref command within \title for footnotes;
88%% use the tnotetext command for the associated footnote;
89%% use the fnref command within \author or \address for footnotes;
90%% use the fntext command for the associated footnote;
91%% use the corref command within \author for corresponding author footnotes;
92%% use the cortext command for the associated footnote;
93%% use the ead command for the email address,
94%% and the form \ead[url] for the home page:
95%%
96%% \title{Title\tnoteref{label1}}
97%% \tnotetext[label1]{}
98%% \author{Name\corref{cor1}\fnref{label2}}
99%% \ead{email address}
100%% \ead[url]{home page}
101%% \fntext[label2]{}
102%% \cortext[cor1]{}
103%% \address{Address\fnref{label3}}
104%% \fntext[label3]{}
105
106\title{DCWoRMS - a tool for simulation of energy efficiency in Grids and Clouds }
107
108%% use optional labels to link authors explicitly to addresses:
109%% \author[label1,label2]{<author name>}
110%% \address[label1]{<address>}
111%% \address[label2]{<address>}
112
113\author{Krzysztof Kurowski, Ariel Oleksiak, Wojciech Piatek, Tomasz Piontek, Andrzej Przybyszewski}
114
115
116\begin{abstract}
117%% Text of abstract
118
119In the recent years, energy-efficiency of computing infrastructures has gained a great attention. For this reason, proper estimation and evaluation of energy that is required to execute grid and cloud workloads became an important research problem. In this paper we present a Data Center Workload and Resource Management Simulator (DCWoRMS) which enables modeling and simulation of computing infrastructures to estimate their performance, energy consumption, and energy-efficiency metrics for diverse workloads and management policies.
120We discuss methods of power usage modeling available in the simulator. To this end, we compare results of simulations to measurements of real servers.
121To demonstrate DCWoRMS capabilities we evaluate impact of several resource management policies on overall energy-efficiency of specific workloads executed on heterogeneous resources.
122
123\end{abstract}
124
125\begin{keyword}
126%% keywords here, in the form: keyword \sep keyword
127
128%% MSC codes here, in the form: \MSC code \sep code
129%% or \MSC[2008] code \sep code (2000 is the default)
130
131\end{keyword}
132
133\end{frontmatter}
134
135%%
136%% Start line numbering here if you want
137%%
138% \linenumbers
139
140%% main text
141\section{Introduction}
142
143Large-scale computing infrastructures such as grids and clouds caused quick development of data centers. Nowadays, data centers are responsible for around 2\% of the global energy consumption making it equal to the demand of aviation industry \cite{koomey}. In many current data centers the actual IT equipment uses only half of the total energy (e.g. 45-62\% in \cite{hintemann}) while most of the remaining part is required for cooling and air movement resulting in poor Power Usage Effectiveness (PUE) \cite{pue} values. Large energy needs and significant $CO_2$ emissions caused that issues related to cooling, heat transfer, and IT infrastructure location are more and more carefully studied during planning and operation of data centers.
144Even if we take ecological and footprint issues aside, the amount of consumed energy can impose strict limits on data centers. First of all, energy bills may reach millions euros making computations expensive.
145Furthermore, available power supply is usually limited so it also may reduce data center development capabilities, especially looking at challenges related to exascale computing breakthrough foreseen within this decade.
146
147For these reasons many efforts were undertaken to measure and study energy efficiency of data centers. Some of projects focused on data center monitoring and management \cite{games}\cite{fit4green} whereas others on prototypes of low power computing infrastructures \cite{montblanc}. Studies included aspects such as energy efficiency of networks \cite{networks} and service level agreements related to energy consumption \cite{sla}. Additionally, vendors offer a wide spectrum of energy efficient solutions for computing and cooling \cite{sgi}\cite{colt}\cite{ecocooling}. However, a variety of solutions and configuration options can be applied planning new or upgrading existing data centers.
148In order to optimize a design or configuration of data center we need a thorough study using appropriate metrics and tools evaluating how much computation or data processing  can be done within given power and energy budget and how it affects temperatures, heat transfers, and airflows within data center.
149Therefore, there is a need for simulation tools and models that approach the problem from a perspective of end users and take into account all the factors that are critical to understanding and improving the energy efficiency of data centers, in particular, hardware characteristics, applications, management policies, and cooling.
150These tools should support data center designers and operators by answering questions how specific application types, levels of load, hardware specifications, physical arrangements, cooling technology, etc. impact overall data center energy efficiency.
151
152In this paper we present a Data Center Workload and Resource Management Simulator (DCWoRMS) which enables modeling and simulation of computing infrastructures to estimate their performance, energy consumption, and energy-efficiency metrics for diverse workloads and management policies.
153We discuss methods of power usage modeling available in the simulator. To this end, we compare results of simulations to measurements of real servers.
154To demonstrate DCWoRMS capabilities we evaluate impact of several resource management policies on overall energy-efficiency of specific workloads executed on heterogeneous resources.
155
156The remaining part of this paper is organized as follows. In Section~2 we give a brief overview of the current state of the art concerning modeling and simulation of distributed systems, such as Grids and Clouds, in terms of energy efficiency. Section~3 discusses the main features of DCWoRMS. In particular, it introduces our approach to workload and resource management, presents the concept of energy efficiency modeling and explains how to incorporate a specific application performance model into simulations. Section~4 discusses energy models adopted within the DCWoRMS. In Section~5 we assess the energy models by comparison of simulation results with real measurements. We also present experiments that were performed using DCWoRMS to show various types of resource and scheduling technics allowing to decrease the total energy consumption of the execution of a set of tasks. In Section~6 we explain how to integrate workload and resource simulations with heat transfer simulations within the CoolEmAll project. Final conclusions and directions for future work are given in Section~7.
157
158\section{Related Work}
159
160The growing importance of energy-efficiency in information technologies led to significant interest in energy saving methods for computing systems. Nevertheless, studies of impact of resource management policies on energy-efficiency of IT infrastructures require a large effort and are difficult to perform in real distributed environments. To overcome these issues, extensive research has been conducted in the area of modeling and simulation and variety of tools that address the green computing have emerged. The most popular ones are: GreenCloud \cite{GreenCloud}, CloudSim \cite{CloudSim} and DCSG Simulator \cite{DCSG}.
161
162GreenCloud is a C++ based simulation environment for studying the energy-efficiency of cloud computing data centers. CloudSim is a simulation tool that allows modeling of cloud computing environments and evaluation of resource provisioning algorithms. Finally, the DCSG Simulator is a data center cost and energy simulator calculating the power and cooling schema of the data center equipment.
163
164The scope of the aforementioned toolkits concerns the data center environments. However, all of them, except DCWoRMS presented in this paper, imposes and restricts user in terms of modeled resources. GreenCloud defines switches, links and servers that are responsible for task execution and may contain different scheduling strategies. Contrary to what the GreenCloud name may suggest, it does not allow testing the impact of a virtualization-based approaches. CloudSim allows creating a simple resources hierarchy consisting of machines and processors. To simulate a real cloud computing data center, it provides an extra virtualization layer responsible for the VM provisioning process and managing the VM life cycle. In DCSG Simulator user is able to take into account a variety of mechanical and electrical devices as well as the IT equipment and define for each of them numerous factors, including device capacity and efficiency as well as the data center conditions.
165
166The general idea behind all of the analyzed tools is to enable studies concerning energy efficiency in distributed infrastructures. GreenCloud approach enables simulation of energy usage associated with computing servers and network components. For example, the server power consumption model implemented in GreenCloud depends on the server state as well as its utilization. The CloudSim framework provides basic models to evaluate energy-conscious provisioning policies. Each computing node can be extended with a power model that estimates the current the power consumption. Within the DCSG Simulator, performance of each data center equipment (facility and IT) is determined by a combination of factors, including workload, local conditions, the manufacturer's specifications and the way in which it is utilized. In DCWoRMS, the plugin idea has been introduced that offers emulating the behavior of computing resources in terms of power consumption. Additionally, it delivers detailed information concerning resource and application characteristics needed to define more sophisticated power draw models.
167
168In order to emulate the behavior of real computing systems, green computing simulator should address also the energy-aware resource management. In this term, GreenCloud offers capturing the effects of both of the Dynamic Voltage and Frequency Scaling (DVFS) and Dynamic Power Management schemes. At the links and switches level, it supports downgrading the transmission rate and putting network equipment into a sleep mode. CloudSim comes with a set of predefined and extensible policies that manage the process of VM migrations in order to optimize the power consumption. However, the proposed approach is not sufficient for modeling more sophisticated policies like frequency scaling techniques and managing resource power states. Romonet’s tool is told to implement a set of basic energy-efficient rules that have been developed on the basis of detailed understanding of the data center as a system. The output of this simulation is a set of energy, like PUE, and cost data representing the IT devices. DCWoRMS introduces a dedicated interface that provides methods to obtain the detailed information about each resource and its components energy consumption and allows changing its current energy state. Availability of these interfaces in scheduling plugin supports implementation of various strategies such as centralized energy management, self-management of computing resources and mixed models.
169
170In terms of application modeling, all tools, except DCSG Simulator, describe the application with a number of computational and communicational requirements. In addition, GreenCloud and DCWoRMS allow introducing the QoS requirements (typical for cloud computing applications) by taking into account the time constraints during the simulation. DCSG Simulator instead of modeling of the single application, enables the definition of workload that leads to a given utilization level. However, only DCWoRMS supports application performance modeling by not only incorporating simple requirements that are taken into account during scheduling, but also by allowing specification of task execution time.
171
172GreenCloud, CloudSim and DCWoRMS are released as Open Source under the GPL. Romonet’s tool is available under an OSL V3.0 open-source license, however, it can be only accessed by the DCSG members.
173
174Summarizing, DCWoRMS stands out from other tools due to the flexibility in terms of data center equipment and structure definition.
175Moreover, it allows to associate the energy consumption not only with the current power state and resource utilization but also with the particular set of applications running on it. Moreover, it does not limit the user in defining various types of resource management polices. The main strength of CloudSim lies in implementation of the complex scheduling and task execution schemes involving resource virtualization techniques. However,the energy efficiency aspect is limited only to the VM management, The GreenCloud focuses on data center resources with particular attention to the network infrastructure and the most popular energy management approaches. DCSG simulator allows to take into account also non-computing devices, nevertheless it seems to be hardly customizable tool.
176
177\section{DCWoRMS}
178
179The following picture (Figure~\ref{fig:arch}) presents the overall architecture of the simulation tool.
180
181Data Center workload and resource management simulator (DCWoRMS) is a simulation tool based on the GSSIM framework \cite{GSSIM} developed by Poznan Supercomputing and Networking Center (PSNC).
182GSSIM has been proposed to provide an automated tool for experimental studies of various resource management and scheduling strategies in distributed computing systems. DCWoRMS extends its basic functionality and adds some additional features related to the energy efficiency issues in data centers. In this section we will introduce the functionality of the simulator, in terms of modeling and simulation of large scale distributed systems like Grids and Clouds.
183
184
185\subsection{Architecture}
186
187
188\begin{figure}[tbp]
189\centering
190\includegraphics[width = 12cm]{fig/arch.png}
191\caption{\label{fig:arch} DCWoRMS architecture}
192\end{figure}
193
194DCWoRMS is an event-driven simulation tool written in Java. In general, input data for the DCWoRMS consist of workload and resources descriptions. They can be provided by the user, read from real traces or generated using the generator module. However, the key elements of the presented architecture are plugins. They allow the researchers to configure and adapt the simulation environment to the peculiarities of their studies, starting from modeling job performance, through energy estimations up to implementation of resource management and scheduling policies. Each plugin can be implemented independently and plugged into a specific experiment. Results of experiments are collected, aggregated, and visualized using the statistics module. Due to a modular and plug-able architecture DCWoRMS can be applied to specific resource management problems and address different users’ requirements.
195
196
197\subsection{Workload modeling}
198
199As it was said, experiments performed in DCWoRMS require a description of applications that will be scheduled during the simulation. As a primary definition, DCWoRMS uses files in the Standard Workload Format (SWF) or its extension the Grid Workload Format (GWF) \cite{GWF}. In addition to the SWF file, some more detailed specification of a job and tasks can be included in an auxiliary XML file. This form of description provides the scheduler with more detailed information about application profile, task requirements, user preferences and execution time constraints, which are unavailable in SWF/GWF files. To facilitate the process of adapting the traces from real resource management systems, DCWoRMS supports reading those delivered from the most common ones like SLURM \cite{SLURM} and Torque \cite{TORQUE}.
200Since the applications may vary depending on their nature in terms of their requirements and structure, DCWoRMS provides user flexibility in defining the application model. Thus, considered workloads may have various shapes and levels of complexity that range from multiple independent jobs, through large-scale parallel applications, up to whole workflows containing time dependencies and preceding constraints between jobs and tasks. Each job may consist of one or more tasks and these can be seen as groups of processes. Moreover, DCWoRMS is able to handle rigid and moldable jobs, as well as pre-emptive ones. To model the application profile in more detail,
201DCWoRMS follows the DNA approach proposed in \cite{Ghislain}. Accordingly, each task can be presented as a sequence of phases, which shows the impact of this task on the resources that run it. Phases are then periods of time where the system is stable (load, network, memory) given a certain threshold. Each phase is linked to values of the system that represent a resource consumption profile. Such a stage could be for example described as follows: “60\% CPU, 30\% net, 10\% mem.”
202
203Levels of information about incoming jobs are presented in Figure~\ref{fig:jobsStructure}.
204
205
206\begin{figure}[tbp]
207\centering
208\includegraphics[width = 8cm]{fig/jobsStructure.png}
209\caption{\label{fig:jobsStructure} Levels of information about jobs}
210\end{figure}
211
212
213This form of representation allows users to define a wide range of workloads:
214HPC (long jobs, computational-intensive, hard to migrate) or virtualization (short requests) typical for cloud computing environments.
215Further, the DCWoRMS benefits from the GSSIM workload generator tool and extends it with that allows creating synthetic workloads.
216
217
218\subsection{Resource modeling}
219
220The main goal of DCWoRMS is to enable researchers evaluation of various resource management policies in diverse computing environments. To this end, it supports flexible definition of simulated resources both on physical (computing resources) as well as on logical (scheduling entities) level. This flexible approach allows modeling of various computing entities consisting of compute nodes, processors and cores. In addition, detailed location of the given resources can be provided in order to group them and arrange into physical structures such as racks and containers. Each of the components may be described by different parameters specifying available memory, storage capabilities, processor speed etc. In this way, it is possible to describe power distribution system and cooling devices. Due to an extensible description, users are able to define a number of experiment-specific and visionary characteristics. Moreover, with every component, dedicated profiles can be associated that determines, among others, power, thermal and air throughput properties. The energy estimation plugin can be bundled with each resource. This allows defining various power models that can be then followed by different computing system components. Details concerning the approach to energy-efficiency modeling in DCWoRMS can be found in the next sections.
221
222Scheduling entities allow providing data related to the brokering or queuing system characteristics. Thus, information about available queues, resources associated with them and their parameters like priority, availability of AR mechanism etc. can be defined. Moreover, allocation policy and task scheduling strategy for each scheduling entity can be introduced in form of the reference to an appropriate plugin. DCWoRMS allows building a hierarchy of schedulers corresponding to the hierarchy of resource components over which the task may be distributed.
223
224In this way, the DCWoRMS supports simulation of a wide scope of physical and logical architectural patterns that may span from a single computing resource up to whole data centers or geographically distributed grids and clouds. In particular, it supports simulating complex distributed architectures containing models of the whole data centers, containers, racks, nodes, etc. In addition, new resources and distributed computing entities can easily be added to the DCWoRMS environment in order to enhance the functionality of the tool and address more sophisticated requirements. Granularity of such topologies may also differ from coarse-grained to very fine-grained modeling single cores, memory hierarchies and other hardware details.
225
226
227\subsection{Energy management concept in DCWoRMS}
228
229The DCWoRMS allows researchers to take into account energy efficiency and thermal issues in distributed computing experiments. That can be achieved by the means of appropriate models and profiles. In general, the main goal of the models is to emulate the behavior of the real computing resources, while profiles support models by providing data essential for the power consumption calculations. Introducing particular models into the simulation environment is possible through choosing or implementation of dedicated energy plugins that contain methods to calculate power usage of resources, their temperature and system air throughput values. Presence of detailed resource usage information, current resource energy and thermal state description and a functional energy management interface enables an implementation of energy-aware scheduling algorithms. Resource energy consumption and thermal metrics become in this context an additional criterion in the resource management process. Scheduling plugins are provided with dedicated interfaces, which allow them to collect detailed information about computing resource components and to affect their behavior.
230The following subsections present the general idea behind the energy-efficiency simulations.
231
232
233\subsubsection{Power management}
234
235The motivation behind introducing a power management concept in DCWoRMS is providing researchers with the means to define the energy efficiency of resources, dependency of energy consumption on resource load and specific applications, and to manage power modes of resources. Proposed solution extends the power management concept presented in GSSIM \cite{GSSIM_Energy} by offering a much more granular approach with the possibility of plugging energy consumption models and power profiles into each resource level.
236
237\paragraph{\textbf{Power profile}}
238In general, power profiles allow specifying the power usage of resources. Depending on the accuracy of the model, users may provide additional information about power states which are supported by the resources, amounts of energy consumed in these states, and other information essential to calculate the total energy consumed by the resource during runtime. In such a way each component of IT infrastructure may be described, including computing resources, system components and data center facilities. Moreover, it is possible to define any number of new, resource specific, states, for example so called P-states, in which processor can operate.
239
240\paragraph{\textbf{Power consumption model}}
241The main aim of these models is to emulate the behavior of the real computing resource and the way it consumes energy. Due to a rich functionality and flexible environment description, DCWoRMS can be used to verify a number of theoretical assumptions and to develop new energy consumption models. Modeling of energy consumption is realized by the energy estimation plugin that calculates energy usage based on information about the resource power profile, resource utilization, and the application profile including energy consumption and heat production metrics. Relation between model and power profile is illustrated in Figure~\ref{fig:powerModel}.
242
243\begin{figure}[tbp]
244\centering
245\includegraphics[width = 8cm]{fig/powerModel.png}
246\caption{\label{fig:powerModel} Power consumption modeling}
247\end{figure}
248
249\paragraph{\textbf{Power management interface}}
250DCWoRMS is complemented with an interface that allows scheduling plugins to collect detailed power information about computing resource components and to change their power states. It enables performing various operations on the given resources, including dynamically changing the frequency level of a single processor, turning off/on computing resources etc. The activities performed with this interface find a reflection in total amount of energy consumed by the resource during simulation.
251
252Presence of detailed resource usage information, current resource energy state description and functional energy management interface enables an implementation of energy-aware scheduling algorithms. Resource energy consumption becomes in this context an additional criterion in the scheduling process, which use various techniques to decrease energy consumption, e.g. workload consolidation, moving tasks between resources to reduce a number of running resources, dynamic power management, cutting down CPU frequency, and others.
253
254\subsubsection{Air throughput management concept}
255
256The presence of an air throughput concept addresses the issue of resource air-cooling facilities provisioning. Using the air throughput profiles and models allows anticipating the air flow level on output of the computing system component, resulting from air-cooling equipment management.
257
258\paragraph{\textbf{Air throughput profile}}
259The air throughput profile, analogously to the power profile, allows specifying supported air flow states. Each air throughput state definition consists of an air flow value and a corresponding power draw. It can represent, for instance, a fan working state. In this way, associating the air throughput profile with the given computing resource, it is possible to describe mounted air-cooling devices.
260Possibility of introducing additional parameters makes the air throughput description extensible for new specific characteristics.
261
262\paragraph{\textbf{Air throughput model}}
263Similar to energy consumption models, the user is provided with a dedicated interface that allows him to describe the resulting air throughput of the computing system components like cabinets or server fans. The general idea of the air throughput modeling is shown in Figure~\ref{fig:airModel}. Accordingly, air flow estimations are based on detailed information about the involved resources, including their air throughput states.
264
265\begin{figure}[tbp]
266\centering
267\includegraphics[width = 8cm]{fig/airModel.png}
268\caption{\label{fig:airModel} Air throughput modeling}
269\end{figure}
270
271\paragraph{\textbf{Air throughput management interface}}
272The DCWoRMS delivers interfaces that provide access to the air throughput profile data, allows acquiring detailed information concerning current air flow conditions and changes in air flow states. The availability of these interfaces support evaluation of different cooling strategies.
273
274
275
276\subsubsection{Thermal management concept}
277
278The primary motivation behind the incorporation of thermal aspects in the DCWoRMS is to exceed the commonly adopted energy use-cases and apply more sophisticated scenarios. By the means of dedicated profiles and interfaces, it is possible to perform experimental studies involving temperature-aware workload placement.
279
280\paragraph{\textbf{Thermal profile}}
281Thermal profile expresses the thermal specification of resources. It consists of the definition of the thermal design power (TDP), thermal resistance and thermal states that describe how the temperature depends on dissipated heat. For the purposes of more complex experiments, introducing of new, user-defined characteristics is supported. The aforementioned values may be provided for all computing system components distinguishing them, for instance, according to their material parameters and/or models.
282
283\paragraph{\textbf{Temperature estimation model}}
284Thermal profile, complemented with the temperature measurement model implementation may introduce temperature sensors simulation. In this way, users have means to approximately predict the temperature of the simulated objects by taking into account basic thermal characteristics as well as the estimated impact of cooling devices. However, the proposed approach assumes some simplifications that ignore heating and cooling dynamics understood as a heat flow process.
285
286Figure~\ref{fig:tempModel} summarizes relation between model and profile and input data.
287
288\begin{figure}[tbp]
289\centering
290\includegraphics[width = 8cm]{fig/tempModel.png}
291\caption{\label{fig:tempModel} Temperature estimation modeling}
292\end{figure}
293
294\paragraph{\textbf{Thermal resource management interface}}
295As the temperature is highly dependent on the dissipated heat and cooling capacity, thermal resource management is performed via a power and air throughput interface. Nevertheless, the interface provides access to the thermal resource characteristics and the current temperature values
296
297
298\subsection{Application performance modeling}\label{sec:apps}
299
300In general, DCWoRMS implements user application models as objects describing computational, communicational as well as energy requirements and profiles of the task to be scheduled. Additionally, simulator provides means to include complex and specific application performance models during simulations. They allow researchers to introduce specific ways of calculating task execution time. These models can be plugged into the simulation environment through a dedicated API and implementation of an appropriate plugin. To specify the execution time of a task user can apply a number of parameters, including:
301\begin{itemize}
302  \item  task length (number of CPU instructions)
303  \item task requirements
304  \item detailed description of allocated resources (processor type and
305parameters, available memory)
306  \item input data size
307  \item network parameters
308\end{itemize}
309Using these parameters developers can for instance take into account the architectures of the underlying systems, such as multi-core processors, or virtualization overheads, and their impact on the final performance of applications.
310
311
312
313\section{Modeling of energy efficiency in DCWoRMS}
314
315DCWoRMS is an open framework in which various models and algorithms can be investigated as presented in Section \ref{sec:apps}. We discuss possible approaches to modeling that can be applied to simulation of energy-efficiency of distributed computing systems in this section. Additionally, to facilitate the simulation process, DCWoRMS provides some basic implementation of power consumption, air throughput and thermal models. We described them as examples and validate part of them by experiments in real computing system (in Section \ref{sec:experiments}).
316
317The most common questions explored by researchers who study energy-efficiency of distributed computing systems is how much energy $E$ do these systems require to execute workloads. In order to obtain this value the simulator must calculate values of power $P_i(t)$ and load $L_i(t)$ in time for all $m$ computing nodes, $i=1..m$. Load function may depend on specific load models applied. In more complex cases it can even be defined as vectors of different resource usage in time. In a simple case load can be either idle or busy but even in this case estimation of job processing times $p_j$ is needed to calculate total energy consumption. The total energy consumption of computing nodes is given by (\ref{eq:E}):
318
319\begin{equation}
320E=\sum_i^m{\int_t{P_i(t)}} \label{eq:E}
321\end{equation}
322
323
324Power function may depend on load and states of resources or even specific applications as explained in \ref{sec:power}. Total energy can be also completed by adding constant power usage of components that does not depend on load or state of resources.
325
326In large computing systems which are often characterized by high computational density, total energy consumption of computing nodes is not the only result interesting for researchers. Temperature distribution is getting more and more important as it affects energy consumption of cooling devices, which can reach even half of a total data center energy use. In order to obtain accurate values of temperatures heat transfer simulations based on the Computational Fluid Dynamics (CFD) methods  have to be performed. These methods require as an input (i.e. boundary conditions) a heat dissipated by IT hardware and air throughput generated by fans at servers' outlets. Another approach is based on simplified thermal models that without costly CFD calculations provide rough estimations of temperatures. DCWoRMS enables the use of either approaches. In the the former, the output of simulations including power usage of computing nodes in time and air throughput at node outlets can be passed to CFD solver. This option is further elaborated in Section \ref{sec:coolemall}. Simplified thermal models required by the latter approach are proposed in \ref{sec:thermal}.
327
328
329\subsection{Power consumption models}\label{sec:power}
330
331As stated above power usage of computing nodes depend on a number of factors.
332
333Generally, the power consumption of a modern CPU is given by the Ohm's law:
334%\cite{intel_speedstep}:
335
336\begin{equation}
337P=C\cdot V_{core}^{2}\cdot f\label{eq:ohm-law}
338\end{equation}
339
340with $C$ being the processor switching capacitance, $V_{core}$ the
341current P-State's core voltage and $f$ the frequency. Based on the
342above equation it is suggested that although the reduction of frequency
343causes an increase in the time of execution, the reduction of frequency
344also leads to the reduction of $V_{core}$ and thus the power savings
345from the $P\sim V_{core}^{2}$ relation outweigh the increased computation
346time. However, experiments performed on several HPC servers shown that this dependency does not reflect theoretical shape and is often close to linear as presented in Figure \ref{fig:power}. This phenomenon can be explained by impact of other component than CPU and narrow range of available voltages. A good example of impact by other components is power usage of servers with visible influence of fans as illustrated in Figure \ref{fig:fans_P}.
347
348%
349\begin{figure}\label{fig:power}
350\centering
351\includegraphics[width=6cm]{fig/power_default}
352\caption{Average power usage with regard to CPU frequency\protect \\
353\textbf{Tests}: Linpack (\emph{green}), Abinit (\emph{purple}),
354Namd (\emph{blue}) and Cpuburn (\emph{red}). \protect \\
355}
356%
357\end{figure}
358
359\begin{figure}[tbp]
360\centering
361\includegraphics[width = 8cm]{fig/power-fans.png}
362\caption{\label{fig:fans_P} Power in time for highest frequency}
363\end{figure}
364
365
366For these reasons, DCWoRMS allows users to define dependencies between power usage and resource states (such as CPU frequency) in the form of tables or arbitrary functions using energy estimation plugins.
367
368The energy consumption models provided by default can be classified into the following groups, starting from the simplest model up to the more complex ones. Users can easily switch between the given models and incorporate new, visionary scenarios.
369
370\textbf{Static approach} is based on a static definition of resource power usage. This model calculates the total amount of energy consumed by the computing resource system as a sum of energy, consumed by all its components (processors, disks, power adapters, etc.). More advanced versions of this approach assume definition of resource states along with corresponding power usage. This model follows changes of resource power states and sums up the amounts of energy defined for each state.
371In this case, specific values of power usage are defined for all discrete $n$ states as shown in (\ref{eq:static}):
372
373\begin{equation}
374S_1 \to P_1, S_2 \to P_2, ..., S_n \to P_\label{eq:static}
375\end{equation}
376
377\textbf{Resource load} model extends the static power state description and enhances it with real-time resource usage, most often simply the processor load. In this way it enables a dynamic estimation of power usage based on resource basic power usage and state (defined by the static resource description) as well as resource load. For instance, it allows distinguishing between the amount of energy used by idle processors and processors at full load. In this manner, energy consumption is directly connected with power state and describes average power usage by the resource working in a current state.
378In this case, specific values of power usage are defined for all pairs state and load values (discretized to $l$ values) as shown in (\ref{eq:load}):
379
380\begin{equation}
381(S_1, L_1) \to P_{11}, (S_1, L_2) \to P_{12}, ...,  (S_2, L_1) \to P_{21}, ..., (S_n, L_l) \to P_{nl}\label{eq:load}
382\end{equation}
383
384\textbf{Application specific} model allows expressing differences in the amount of energy required for executing various types of applications at diverse computing resources. It considers all defined system elements (processors, memory, disk, etc.), which are significant in total energy consumption. Moreover, it also assumes that each of these components can be utilized in a different way during the experiment and thus have different impact on total energy consumption. To this end, specific characteristics of resources and applications are taken into consideration. Various approaches are possible including making the estimated power usage dependent on defined classes of applications, ratio between CPU-bound and IO-bound operations, etc.
385In this case, power usage is an arbitrary function of state, load, and application characteristics as shown in (\ref{eq:app}):
386
387\begin{equation}
388f(S, L, A) \to P \label{eq:app}
389\end{equation}
390
391\subsection{Air throughput models}\label{sec:air}
392
393The DCWoRMS comes with the following air throughput models.
394By default, air throughput estimations are performed according to the first one.
395
396\textbf{Static} model refers to a static definition of air throughput states. According to this approach, output air flow depends only on the present air cooling working state and the corresponding air throughput value. Each state change triggers the calculations and updates the current air throughput value. This strategy requires only a basic air throughput profile definition.
397
398\textbf{Space} model allows taking into account a duct associated with the investigated air flow. On the basis of the given fan rotation speed and the obstacles before/behind the fans, the output air throughput can be roughly estimated. To this end, additional manufacturer's specifications will be required, including resulting air velocity values and fan duct dimensions. Thus, it is possible to estimate the air flow level not only referring to the current fan operating state but also with respect to the resource and its subcomponent placement. More advanced scenario may consider mutual impact of several air flows.
399
400\subsection{Thermal models}\label{sec:thermal}
401
402\begin{figure}[tbp]
403\centering
404\includegraphics[width = 8cm]{fig/temp-fans.png}
405\caption{\label{fig:tempModel} Temperature in time for highest frequency}
406\end{figure}
407
408
409The following models are supported natively. By default, the static strategy is applied.
410
411\textbf{Static} approach follows the changes in heat, generated by the computing system components and matches the corresponding temperature according to the specified profile. Since it tracks the power consumption variations, corresponding values must be delivered, either from power consumption model or on the basis of user data. Replacing the appropriate temperature values with function based on the defined material properties and/o experimentally measured values can easily extend this model.
412
413\textbf{Ambient} model allows taking into account the surrounding cooling infrastructure. It calculates the device temperature as a function adopted from the static approach and extends it with the influence of cooling method. The efficiency of cooling system may be derived from the current air throughput value.
414
415\section{Experiments and evaluation}\label{sec:experiments}
416
417TODO - correct, improve, refactor...
418
419In this section, we present computational analysis that were conducted to emphasize the role of modelling and simulation in studying computing systems performance. To this end we evaluate the impact of energy-aware resource management policies on overall energy-efficiency of specific workloads on heterogeneous resources. The following sections contain description of the used system, tested application and the results of simulation experiments conducted for the evaluated strategies.
420
421\subsection{Testbed description}
422
423To obtain values of power consumption that could be later used in DCWoRMS environment to build the model and to evaluate resource management policies we ran a set of applications / benchmarks on the physical testbed. For experimental purposes we choose the high-density Resource Efficient Cluster Server (RECS) system. The single RECS unit consists of 18 single CPU modules, each of them can be treated as an individual node of PC class. Configuration of our RECS unit is presented in Table~\ref{testBed}.
424
425\begin {table}[h!]
426\centering
427\begin{tabular}{llr}
428\hline
429\multicolumn{3}{c}{Nodes} \\
430Type & Memory (RAM) & Count  \\
431\hline
432 Intel i7 & 16 GB &     8 \\
433AMD Fusion T40N 64 Bit & 4 GB   & 6 \\
434Atom D510 64 Bit & 2 GB &       4 \\
435\hline
436%\multicolumn{3}{c}{Storage} \\
437%Type & Size & Connection  \\
438%\hline
439%Storage Head 520 & 16 x 300 GB SSD & 2 x 10 Gbit/s CX4 \\
440%\hline
441\end{tabular}
442\caption {\label{testBed} RECS system configuration}
443\end {table}
444
445
446The RECS system was chosen due to its heterogeneous platform with very high density and energy efficiency that has a monitoring and controlling mechanism integrated. The built-in and additional sensors allow monitoring the complete testbed at a very fine granularity level without the negative impact of the computing- and network-resources.
447
448
449\subsection{Evaluated applications}
450
451As mentioned, first we carried out a set of tests on the real hardware used as a CoolEmAll testbed to build the performance and energy profiles of applications. Then we applied this data into the simulation environment and used to investigate different approaches to energy-aware resource management. The following applications were taken into account:
452
453\textbf{Abinit} is a widely-used application for computational physics simulating systems made of electrons and nuclei to be calculated within density functional theory.
454
455\textbf{C-Ray} is a ray-tracing benchmark that stresses floating point performance of a CPU. Our test is configured with the 'scene' file at 16000x9000 resolution.
456
457\textbf{Linpack} benchmark is used to evaluate system floating point performance. It is based on the Gaussian elimination methods that solve a dense N by N system of linear equations.
458
459\textbf{Tar} it is a widely used data archiving software]. In our tests the task was to create one compressed file of Linux kernel (version 3.4), which is about 2,3 GB size, using bzip2.
460
461\textbf{FFTE} benchmark measures the floating-point arithmetic rate of double precision complex one-dimensional Discrete Fourier Transforms of 1-, 2-, and 3-dimensional sequences of length $2^{p} * 3^{q} * 5^{r}$. In our tests only one core was used to run the application.
462
463
464\subsection{Methodology}
465
466Every chosen application / benchmark was executed on each type of node, for all frequencies supported by the CPU and for different levels of parallelization (number of cores). To eliminate the problem with assessing which part of the power consumption comes from which application, in case when more then one application is ran on the node, the queuing system (SLURM) was configured to run jobs in exclusive mode (one job per node). Such configuration is often used for at least dedicated part of HPC resources. The advantage of the exclusive mode scheduling policy consist in that the job gets all the resources of the assigned nodes for optimal parallel performance and applications running on the same node do not influence each other. For every configuration of application, type of node and CPU frequency we measure the average power consumption of the node and the execution time. The aforementioned values  were used to configure the DCWoRMS environment providing energy and time execution models.
467Based on the models obtained for the considered set of resources and applications we evaluated a set of resource management strategies in terms of energy consumption needed to execute three workloads varying in load intensity (10\%, 30\%, 50\%, 70\%).
468To generate a workload we used the DCWoRMS workload generator tool using the following characteristics (Table~\ref{workloadCharacteristics}).
469
470\begin {table}[ tp]
471\centering
472\begin{tabular}{l c c c c r}
473\hline
474 & \multicolumn{4}{c}{Load intensity} & \\
475Characteristic & 10  & 30 & 50 & 70  & Distribution\\
476\hline
477Task Count & \multicolumn{4}{c}{1000} & constant\\
478\hline
479Task Interval [s] & 3000 & 1200 & 720 & 520 & poisson\\
480\hline
481\multirow{8}{*}{Number of cores to run}  & \multicolumn{4}{c}{1} & uniform - 30\%\\
482 & \multicolumn{4}{c}{2} & uniform - 30\%\\
483 & \multicolumn{4}{c}{3} & uniform - 10\%\\
484 & \multicolumn{4}{c}{4} & uniform - 10\%\\
485 & \multicolumn{4}{c}{5} & uniform - 5\%\\
486 & \multicolumn{4}{c}{6} & uniform - 5\%\\
487 & \multicolumn{4}{c}{7} & uniform - 5\%\\
488 & \multicolumn{4}{c}{8} & uniform - 5\%\\
489\hline
490\multirow{5}{*}{Application type}  & \multicolumn{4}{c}{Abinit} & uniform - 20\%\\
491 & \multicolumn{4}{c}{C-Ray} & uniform - 20\%\\
492 & \multicolumn{4}{c}{Tar} & uniform - 20\%\\
493 & \multicolumn{4}{c}{Linpack - 3Gb} & uniform - 10\%\\
494 & \multicolumn{4}{c}{Linpack - tiny} & uniform - 10\%\\
495 & \multicolumn{4}{c}{FFT} & uniform - 20\%\\
496
497\hline
498\end{tabular}
499\caption {\label{workloadCharacteristics} Workload characteristics}
500\end {table}
501
502In all cases we assumed that tasks are scheduled and served in order of their arrival (FIFO strategy) with easy backfilling approach.
503
504\subsection{Computational analysis}
505
506In the following section we present the results obtained for the workload with load density equal to 70\% in the light of five resource management and scheduling strategies. The scheduling strategies were evaluated according to two criteria: total energy consumption and maximum completion time of all tasks (makespan). These evaluation criteria employed in our experiments represent interests of various groups of stakeholders present in clouds and grids.
507Then we discusses the corresponding results received for workloads with other density level.
508
509\subsubsection{Random approach}
510
511The first considered by us policy was the Random strategy in which tasks were assigned to nodes in random manner with the reservation that they can be assigned only to nodes of the type which the application was possible to execute on and we have the corresponding value of power consumption and execution time. The Random strategy is only the reference one and will be later used to compare benefits in terms of energy efficiency resulting from more sophisticated algorithms. Criteria values are as follows: \textbf{total energy usage}: 46,883 kWh, \textbf{workload completion time}: 533 820 s.
512Figure~\ref{fig:70r} presents the energy consumption, load of the system and obtained schedule, respectively.
513
514
515\begin{figure}[h!]
516\centering
517\includegraphics[width = 12cm]{fig/70r.png}
518\caption{\label{fig:70r} Random strategy}
519\end{figure}
520
521In the second version of this strategy, which is getting more popular due to energy costs, we switched of unused nodes to reduce the total energy consumption. In the previous one, unused nodes are not switched off, which case is still the primary one in many HPC centers.
522
523\begin{figure}[h!]
524\centering
525\includegraphics[width = 6cm]{fig/70rnpm.png}
526\caption{\label{fig:70rnpm} Random + switching off unused nodes strategy}
527\end{figure}
528
529In this version of experiment we neglected additional cost and time necessary to change the power state of resources. As can be observed in the power consumption chart in the Figure~\ref{fig:70rnpm}, switching of unused nodes led to decrease of the total energy consumption. As expected, with respect to the makespan criterion, both approaches perform equally reaching \textbf{workload completion time}: 533 820 s. However, the pure random strategy was significantly outperformed in terms of energy usage, by the policy with additional node power management with its \textbf{total energy usage}: 36,705 kWh. The overall energy savings reached 22\%.
530
531\subsubsection{Energy optimization}
532
533The next two evaluate resource management strategies try to decrease the total energy consumption needed to execute the whole workload taking into account differences in applications and hardware profiles. We tried to match both profiles to find the more energy efficient assignment. In the first case we assumed that there is again no possibility to switch off unused nodes, thus for the whole time needed to execute workload nodes consume at least power for idle state. To obtain the minimal energy consumption, tasks has to be assigned to the nodes of type for which the difference between energy consumption for the node running the application and in the idle state is minimal. The power usage measured in idle state for three types of nodes is gathered in the Table~\ref{idlePower}.
534
535\begin {table}[h!]
536\centering
537\begin{tabular}{ll}
538\hline
539Type & Power usage in idle state [W]  \\
540\hline
541 Intel i7 & 11,5 \\
542AMD Fusion & 19 \\
543Atom D510  & 10 \\
544\hline
545\end{tabular}
546\caption {\label{idlePower} Measured power of testbed nodes in idle state}
547\end {table}
548
549As mentioned, we assign tasks to nodes minimizing the value of expression: $(P-Pidle)*exec\_time$, where $P$ denotes observed power of the node running the particular application and $exec\_time$ refers to the measured application running time. Based on the application and hardware profiles, we expected that Atom D510 would be the preferred node. Obtained schedule, that is presented in the Gantt chart in Figure~\ref{fig:70eo} along with the energy and system usage, confirmed our assumptions. Atom D510 nodes are nearly fully loaded, while the least energy-favourable AMD nodes are used only when other ones are busy.
550
551\begin{figure}[h!]
552\centering
553\includegraphics[width = 12cm]{fig/70eo.png}
554\caption{\label{fig:70eo} Energy usage optimization strategy}
555\end{figure}
556
557This allocation strategy, leads to slight deterioration of makespan criterion, resulting in \textbf{workload completion time} equal to 534 400 s. Nevertheless, the \textbf{total energy usage} is reduced, achieving: 46,305 kWh.
558
559
560The next strategy is similar to the previous one, so making the assignment of task to the node, we still take into consideration application and hardware profiles, but in that case we assume that the system supports possibility of switching off unused nodes. In this case the minimal energy consumption is achieved by assigning the task to the node for which the product of power consumption and time of execution is minimal. In other words we minimized the following expression: $P*exec\_time$.
561Contrary to the previous strategy, we expected Intel I7 nodes to be allocated first. Generated Gantt chart is consistent with our expectations.
562
563\begin{figure}[h!]
564\centering
565\includegraphics[width = 12cm]{fig/70eonpm.png}
566\caption{\label{fig:70eonpm} Energy usage optimization + switching off unused nodes strategy}
567\end{figure}
568
569Estimated \textbf{total energy usage} of the system is 30,568 kWh. As we can see, this approach significantly improved the value of this criterion, comparing to the previous policies. Moreover, the proposed allocation strategy does not worsen the \textbf{workload completion time} criterion, for which the resulting value is equal to 533 820 s.
570
571\subsubsection{Frequency scaling}
572
573The last considered by us case is modification of the random strategy. We assume that tasks do not have deadlines and the only criterion which is taken into consideration is the total energy consumption. In this experiment we configured the simulated infrastructure for the lowest possible frequencies of CPUs. The experiment was intended to check if the benefit of running the workload on less power-consuming frequency of CPU is not leveled by the prolonged time of execution of the workload. The values of the evaluated criteria are as follows: \textbf{workload completion time}: 1 065 356 s and \textbf{total energy usage}: 77,109 kWh. As we can see, for the given load of the system (70\%), the cost of running the workload that requires almost twice more time, can not be compensate by the lower power draw. Moreover, as it can be observed on the charts in Figure~\ref{fig:70dfs}, the execution times on the slowest nodes (Atom D510) visibly exceeds the corresponding values on other servers.
574       
575\begin{figure}[h!]
576\centering
577\includegraphics[width = 12cm]{fig/70dfs.png}
578\caption{\label{fig:70dfs} Frequency downgrading strategy}
579\end{figure}
580
581
582As we were looking for the trade-off between total completion time and energy usage, we were searching for the workload load level that can benefit from the lower system performance in terms of energy-efficiency. For the frequency downgrading policy, we noticed the improvement on the energy usage criterion only for the workload resulting in 10\% system load. For this threshold we observed that slowdown in task execution does not affect the subsequent tasks in the system and thus total completion time of the whole workload.
583       
584
585
586Figure~\ref{fig:dfsComp} shows schedules obtained for Random and DFS strategy.
587
588
589\begin{figure}[h!]
590\centering
591\includegraphics[width = 12cm]{fig/dfsComp.png}
592\caption{\label{fig:dfsComp} Schedules obtained for Random strategy (left) and DFS strategy (right) for 10\% of system load}
593\end{figure}
594
595
596The following tables: Table~\ref{loadEnergy} and Table~\ref{loadMakespan} contain the values of evaluation criteria (total energy usage and makespan respectively) gathered for all investigated workloads.
597
598\begin {table}[h!]
599\centering
600\begin{tabular}{l|lllll}
601\hline
602&  \multicolumn{5}{c}{Strategy}\\
603Load  & R & R+NPM & EO & EO+NPM & DFS\\
604\hline
60510\% & 241,337 &        37,811 & 239,667 & 25,571 & 239,278 \\
60630\% &89,853 & 38,059 & 88,823 & 25,595 & 90,545 \\
60750\% &59,112 & 36,797 & 58,524 & 26,328 & 76,020 \\
60870\% &46,883 & 36,705 & 46,305 & 30,568 & 77,109 \\
609\hline
610\end{tabular}
611\caption {\label{loadEnergy} Energy usage [kWh] for different level of system load. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, DFS - Dynamic Frequency Scaling}
612\end {table}
613
614\begin {table}[h!]
615\centering
616\begin{tabular}{l|lllll}
617\hline
618&  \multicolumn{5}{c}{Strategy}\\
619Load  & R & R+NPM & EO & EO+NPM & DFS\\
620\hline
62110\% & 3 605 428 & 3 605 428 & 3 605 428 & 3 605 428 & 3 622 968 \\
62230\% & 1 214 464 & 1 214 464 & 1 215 044 & 1 200 807 & 1 275 093 \\
62350\% &729 066& 729 066 & 731 126& 721 617       & 1 049 485\\
62470\% & 533 820 & 533 820 & 534 400 & 533 820 & 1 065 356\\
625\hline
626\end{tabular}
627\caption {\label{loadMakespan} Makespan [s] for different level of system load. R - Random, R+NPM - Random + node power management, EO - Energy optimization, EO+NPM - Energy optimization + node power management, DFS - Dynamic Frequency Scaling}
628\end {table}
629
630Referring to the Table~\ref{loadEnergy}, one should easily note that gain from switching off unused nodes decreases with the increasing workload density. In general, for the highly loaded system such policy does not find an application due to the cost related to this process and relatively small benefits.
631
632
633
634\section{DCWoRMS application/use cases}\label{sec:coolemall}
635
636DCWoRMS in CoolEmAll, integration with CFD
637
638...
639
640Being based on the GSSIM framework, that has been successfully applied in a substantial number of research projects and academic studies, DCWoRMS with its sophisticated energy extension has become an essential tool for studies of energy efficiency in distributed environments. For this reason, it has been adopted within the CoolEmAll project as a component of Simulation, Visualisation and Decision Support (SVD) Toolkit. In general the main goal of CoolEmAll is to provide advanced simulation, visualisation and decision support tools along with blueprints of computing building blocks for modular data centre environments. Once developed, these tools and blueprints should help to minimise the energy consumption, and consequently the CO2 emissions of the whole IT infrastructure with related facilities. The SVD Toolkit is designed to support the analysis and optimization of IT modern infrastructures. For the recent years the special attention has been paid for energy utilized by the data centers which considerable contributes to the data center operational costs.  Actual power usage and effectiveness of energy saving methods heavily depends on available resources, types of applications and workload properties. Therefore, intelligent resource management policies are gaining popularity when considering the energy efficiency of IT infrastructures.
641Hence, SVD Toolkit integrates also workload management and scheduling policies to support complex modeling and optimization of modern data centres.
642
643The main aim of DCWoRMS within CoolEmAll project is to enable studies of dynamic states of IT infrastructures, like power consumption and air throughput distribution, on the basis of changing workloads, resource model and energy-aware resource management policies.
644In this context, DCWoRMS takes into account the specific workload and application characteristics as well as detailed resource parameters. It will benefit from the CoolEmAll benchmarks and classification of applications and workloads. In particular various types of workload, including data centre workloads using virtualization and HPC applications, may be considered. The knowledge concerning their performance and properties as well as information about their energy consumption and heat production will be used in simulations to study their impact on thermal issues and energy efficiency. Detailed resource characteristics, will be also provided according to the CoolEmAll blueprints. Based on this data, workload simulation will support evaluation process of various resource management approaches. These policies may include a wide spectrum of energy-aware strategies such as workload consolidation/migration, dynamic switching off nodes, DVFS and thermal-aware methods. In addition to typical approaches minimizing energy consumption, policies that prevent too high temperatures in the presence of limited cooling (or no cooling) may also be analyzed. Moreover, apart from the set of predefined strategies, new approaches can easily be applied and examined.
645The outcome of the workload and resource management simulation phase is a distribution of power usage and air throughput for the computing models specified within the SVD Toolkit. These statistics may be analyzed directly by data centre designers and administrators and/or provided as an input to the CFD simulation phase. The former case allows studying how the above metrics change over time, while the latter harness CFD simulations to identify temperature differences between the computing modules, called hot spots. The goal of this scenario is to visualise the behavior of the temperature distribution within a server room with a number of racks for different types of executed workloads and for various policies used to manage these workloads.
646
647
648\section{Conclusions and future work}
649
650TODO - Conclusions and future research
651
652\section*{Acknowledgement}
653The results presented in this paper are partially funded by the European Commission under contract 288701 through the project CoolEmAll and by grants
654from Polish National Science Center: a grant under award number 636/N-COST/09/2010/0 and a grant under award number 5790/B/T02/2010/38.
655
656
657\label{}
658
659%% The Appendices part is started with the command \appendix;
660%% appendix sections are then done as normal sections
661%% \appendix
662
663%% \section{}
664%% \label{}
665
666%% References
667%%
668%% Following citation commands can be used in the body text:
669%% Usage of \cite is as follows:
670%%   \cite{key}          ==>>  [#]
671%%   \cite[chap. 2]{key} ==>>  [#, chap. 2]
672%%   \citet{key}         ==>>  Author [#]
673
674%% References with bibTeX database:
675
676%%\bibliographystyle{model1-num-names}
677%%\bibliography{<your-bib-database>}
678
679%% Authors are advised to submit their bibtex database files. They are
680%% requested to list a bibtex style file in the manuscript if they do
681%% not want to use model1-num-names.bst.
682
683%% References without bibTeX database:
684
685 \begin{thebibliography}{00}
686
687%% \bibitem must have the following form:
688%%   \bibitem{key}...
689%%
690
691% \bibitem{}
692
693\bibitem{fit4green} A. Berl, E. Gelenbe, M. di Girolamo, G. Giuliani, H. de Meer, M.-Q. Dang, K. Pentikousis. Energy-Efficient Cloud Computing. The Computer Journal, 53(7), 2010.
694
695\bibitem{CloudSim} Rodrigo N. Calheiros, Rajiv Ranjan, Anton Beloglazov, Cesar A. F. De Rose, and Rajkumar Buyya, CloudSim: A Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation of Resource Provisioning Algorithms, Software: Practice and Experience (SPE), Volume 41, Number 1, Pages: 23-50, ISSN: 0038-0644, Wiley Press, New York, USA, January, 2011.
696
697\bibitem{DCSG} http://dcsg.bcs.org/welcome-dcsg-simulator
698
699\bibitem{DCD_Romonet} http://www.datacenterdynamics.com/blogs/ian-bitterlin/it-does-more-it-says-tin\%E2\%80\%A6
700
701\bibitem{networks} E. Gelenbe and C. Morfopoulou. Power savings in packet networks via optimised routing. Mobile Networks and Applications, 17(1):152–159, February 2012.
702
703\bibitem{Ghislain} Ghislain Landry Tsafack Chetsa, Laurent LefÚvre, Jean-Marc Pierson, Patricia Stolf, Georges Da Costa. “DNA-inspired Scheme for Building the Energy Profile of HPC Systems”. In: International Workshop on Energy-Efficient Data Centres, Madrid, Springer, 2012
704
705\bibitem{games} A. Kipp, L. Schubert, J. Liu, T. Jiang, W. Christmann, M. vor dem Berge (2011). Energy Consumption Optimisation in HPC Service Centres, Proceedings of the Second International Conference on Parallel, Distributed, Grid and Cloud Computing for Engineering, B.H.V. Topping and P. Iványi, (Editors), Civil-Comp Press, Stirlingshire, Scotland
706
707\bibitem{GreenCloud} D. Kliazovich, P. Bouvry, and S. U. Khan, A Packet-level Simulator of Energy- aware Cloud Computing Data Centers, Journal of Supercomputing, vol. 62, no. 3, pp. 1263-1283, 2012
708
709\bibitem{sla} S. Klingert, T. Schulze, C. Bunse. GreenSLAs for the Energy-efficient Management of Data Centres. 2nd International Conference on Energy-Efficient Computing and Networking (e-Energy), 2011.
710
711\bibitem{GSSIM} S. Bak, M. Krystek, K. Kurowski, A. Oleksiak, W. Piatek and J. Weglarz, GSSIM - a Tool for Distributed Computing Experiments, Scientific Programming Journal, vol. 19, no. 4, pp. 231-251, 2011.
712
713\bibitem{GSSIM_Energy} M. Krystek, K. Kurowski, A. Oleksiak, W. Piatek, Energy-aware simulations with GSSIM. Proceedings of the COST Action IC0804 on Energy Efficiency in Large Scale Distributed Systems, 2010, pp. 55-58.
714
715\bibitem{hintemann} Hintemann, R., Fichter, K. (2010). Materialbestand der Rechenzentren in Deutschland, Eine Bestandsaufnahme zur Ermittlung von Ressourcen- und Energieeinsatz, UBA, Texte, 55/2010
716
717\bibitem{koomey}
718Koomey, Jonathan. 2008. "Worldwide electricity used in data centers." Environmental Research Letters. vol. 3, no. 034008. September 23
719
720
721
722% web links
723
724\bibitem{GWF} http://gwa.ewi.tudelft.nl/
725
726\bibitem{SLURM} https://computing.llnl.gov/linux/slurm/
727
728\bibitem{SWF} Parallel Workload Archive, http://www.cs.huji.ac.il/labs/parallel/workload/
729
730\bibitem{TORQUE} http://www.adaptivecomputing.com/products/open-source/torque/
731
732
733\bibitem{colt} Colt Modular Data Centre, http://www.colt.net/uk/en/products-services/data-centre-services/modular-data-centre-en.htm
734
735\bibitem{coolemall} The CoolEmAll project website, http://coolemall.eu
736
737\bibitem{ecocooling} EcoCooling, http://www.ecocooling.org
738
739\bibitem{montblanc} The MontBlanc project website,  http://www.montblanc-project.eu/
740
741\bibitem{pue} The Green Grid Data Center Power Efficiency Metrics: PUE and DCiE, http://www.thegreengrid.org/Global/Content/white-papers/The-Green-Grid-Data-Center-Power-Efficiency-Metrics-PUE-and-DCiE
742
743\bibitem{sgi} SGI ICE Cube Air, http://www.sgi.com/products/data\_center/ice\_cube\_air/
744
745
746 \end{thebibliography}
747
748
749\end{document}
750
751%%
752%% End of file `elsarticle-template-1-num.tex'.
Note: See TracBrowser for help on using the repository browser.