Uwe Wössner

Keywords: Simulation, Visualisation, Virtual Reality, Workload-Simulation, SVD, DEBB, Repository Version: 1.0

This deliverable describes the architectural design of the simulation and visualisation environment of the CoolEmAll project, consisting of a Simulation, Visualisation and Decision support Toolkit (SVD Toolkit). The SVD Toolkit allows the analysis and design of modular IT infrastructures and facilities with resource-efficient cooling, supporting IT infrastructure designers, decision makers and administrators in the process of planning new data centres or improving existing ones.

Table of Tables

Table of Figures

This deliverable aims at describing the architectural design of the simulation and visualisation environment of the CoolEmAll project, which mainly consists of the Simulation, Visualisation and Decision support Toolkit (SVD Toolkit). The SVD Toolkit allows the analysis and design of modular IT infrastructures and facilities with resource-efficient cooling, supporting IT infrastructure designers, decision makers and administrators in the process of planning new data centres or improving existing ones.

The document is structured as follows:

• Chapter 2 presents an overview of the SVD Toolkit architecture.

• Chapter 3 describes in detail each of the components which are part of the overall architecture, as well as their interfaces.

• Chapter 4 details the external interfaces of the SVD Toolkit and the required input from external CoolEmAll components.

• Chapter 5 briefly describes the selected technologies to be used for the implementation of the CoolEmAll SVD Toolkit.

• Chapter 6 briefly describes the external Solvers and visualisation tools which will be used.

SVD Toolkit Use Cases

This chapter presents the overall SVD Toolkit use cases. It describes its different usage purposes and performs a traceability of the requirements identified within WP6, verifying that those are fulfilled by the SVD Toolkit design [D61]. A detailed SOTA analysis was already performed within the previous deliverable [D2 .1].

SVD Toolkit Usage Phases

This section describes the usage phases of the SVD Toolkit. It is important to note that those phases are independent from each other and the end user of the toolkit should be able to select one of them separately. Therefore, the architecture design should consider independent / loosely coupled tools as part of the toolkit which, either combined with each other, or used alone, will support different use cases.

This document does not provide a full set of use cases, but just an overview of the main possibilities of usage of the SVD toolkit. The SVD Toolkit is providing a set of blueprints of computing building blocks (a.k.a. DEBBs models) as well as "Best practices" documentation for users who want to model their own data centre environment. The blueprints provided as part of the SVD Toolkit will be stored in a so called DEBBs repository, which will be accessible by the rest of the tools within the toolkit and, if needed, also by other CoolEmAll components.

For details about DEBBs structure, see [D3.2].

Workload Simulation

The growing importance of energy efficiency in information technologies led to significant interest in thermal management strategies for computing systems. However, the cooling and heat transfer processes are not the only important aspects influencing the energy efficiency of data centres. 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.

Hence, SVD Toolkit integrates also workload management and scheduling policies to support complex modeling and optimization of modern data centres.

The workload simulation process is presented in Figure 2-1. The main aim of this stage 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.

Workload simulation phase 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. The Resource model is based on DEBB description that supports modeling a data centre at various granularity levels. Besides defining simulated architecture, it is complemented with resource energy profiles that become an additional criterion in the workload management process. 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, Dynamic Voltage and Frequency Scaling (DFVS), 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.

The outcome of the workload 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. This second scenario can be realized twofold. First, the input to the CFD simulations may consist of single power usage and air throughput values. They can be obtained for a particular timestamp as well as according to the measurements (avg, min, max, etc.) calculated for a given period of time. On the other hand, CFD simulations may take as an input distribution of power usage and air throughput values over time and perform calculations for the changing boundary conditions. Further, visionary scenario may assume interaction between workload and CFD simulation. It extends the aforementioned cases, by splitting both simulation stages into smaller pieces and adding feedback between them. In this way, resource management simulation will have access to the actual temperature distribution, while CFD simulations will Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 11 / 51 operate on more accurate power and air throughput data. However, this approach requires additional studies concerning performance evaluation.

Apart from being a part of the SVD Toolkit workflow, workload simulations, can be performed separately, simplifying the whole simulation process and giving the user the possibility to benefit from its results in an alternative way, without the necessity of waiting for results of time consuming CFD simulations.

CFD Simulation

One of the usage possibilities of the SVD toolkit is the simulation of airflow and temperature distribution within server rooms, racks and servers. Such a CFD simulation requires the execution of several steps, see Figure 2-2 . It is detailed in the following bullets:

• Geometry Generation, taking as input the previously defined DEBBs models of the concrete resources involved in the simulated environment

• Grid Generation, with the support of meshing tools, resulting in the corresponding computational mesh

• Definition of boundary conditions which are queried from the MOP Database and assigned to the relevant surface patches. Additionally, boundary conditions are set based on results obtained by simulation of workload execution and specific application profiles. These results include power usage and outlet air throughput of IT equipment.

• Domain Partitioning, taking as input the previously generated mesh, together with the boundary conditions.

• Simulation, performed by the ISV Solver.

• Post-processing is performed with the resulting data from the simulation.

• Rendering is performed for the visualisation of the simulation results. Some of it is, in fact, already part of the visualisation usage phase (see below).

• End results of the simulation are written in the MOP Database

Interaction by the end user may be possible, after obtaining the results from the initial simulation, consisting in the following phases:

• Change geometry, e.g. re-arrange racks within server room

Visualisation

The SVD toolkit provides the user with the necessary tools for the visualisation of different kind of elements, which may be a result from previous usage phases:

• Visualisation of CFD Simulation results

• Visualisation of Workload Simulation results

• Visualisation of DEBBs models 3D CFD Simulation results need to be visualised interactively in order to give engineers full access to all required analysis tools provided by standard CFD Simulation and Visualisation environments. The Visualisation and Simulation Environment COVISE provides both interactive analysis on desktop workstations, direct interaction from within immersive 3D virtual environments and tangible interfaces. This allows engineers to use intuitive interfaces to efficiently analyse 3D flow phenomena in fine detail for those usage scenarios where the airflow in servers, racks or server rooms need to be analysed and optimised. For all other simulation scenarios, the COVISE user interface and visualisation functionality will not be used but the required output values such as virtual sensor readings will be automatically extracted from the 3D flow field and stored in the MOP database for further visualisation in the MOP GUI.

Visualisation of Workload simulation results

The general visualisation of data extracted from Workload Simulation will be presented in a form of 2D charts. Dedicated DCWoRMS Statistics Module allows, apart from delivering pure textual data, generation of various number of diagrams presenting resource utilization, power distribution as well as task performance characteristics (with Gantt charts).

Visualisation of DEBB models

DEBB models will be visualized using MOP GUI. Both 3D textured geometries from DEBB models as well as data from the MOP Database, containing simulation results can be presented.

Calculation of Metrics

The SVD Toolkit is providing mechanisms to calculate relevant metrics as a combination of measurements which may come from either real test bed monitoring tools or simulation results. A first selection of those metrics relevant for the CoolEmAll project can be found in [D5.1]. Note that not all those metrics may be directly available from the SVD Toolkit, but a selection of the most relevant ones. Such a selection, as well as the potential identification of new metrics, will be done all along the project lifetime.

Requirements traceability

The SVD toolkit is the simulation toolkit used in WP6 to execute and validate the different use cases defined in the project; hence WP6 has defined a set of requirements to be fulfilled in order to assure the correct execution of the different scenarios. These requirements target the simulation of the physical equipment and more complex tasks like the parameterization of an application or

SVD Toolkit Architecture Overview

As previously mentioned, the SVD toolkit is a set of loosely coupled tools which, either combined with each other or standalone, provide the user with a set of features to perform simulation and visualisation tasks. In this section we describe the overall architecture of the SVD toolkit (section 3.1), relating it to MOP architecture (section 3.2), as presented in D4.1.

In the next section we describe the overall architecture of the SVD toolkit.

Overall architecture

The overall architecture of the SVD toolkit is presented in Figure 3-1.

3

Deliver Compare real data with simulation results

1

Compare measured data with simulated resource utilisation The Application Profiler is an SVD component that is capable of analyzing (step 0) applications (being executed on reference hardware) and generating application profiles, describing the impact of different application phases (tasks) on the resources that execute it. An application profile consists of a sequence of application phases, each described by usage of resources: CPU, Memory, Disk and Network. Application profiles are stored in the Application Profile Repository, and are referenced in workloads, used by the "Data Centre Workload and Resource Management Simulator" in order to assess power consumption of workloads/ applications being virtually executed (simulated) using hardware models abstracting particular resources described in DEBBs, that are stored in the Repository.

The The Data Centre Workload and Resource Management Simulator (also called DCWoRMS in this Deliverable) is a simulation tool based on the GSSIM framework [GSSIM] developed by PSNC. GSSIM provides an automated tool for experimental studies of various resource management and scheduling policies in distributed computing systems. The Data Centre Simulator extends the basic functionality of GSSIM providing assessment of the power consumption of a workload (step 1), being "virtually executed" on scheduled "virtual nodes", well described by a DEBB composition and power profile of DEBBs stored in the DEBB repository (step 2). In addition to power assessment, the Data Centre simulator allows also to calculate air throughput on inlets/outlets of building blocks (of virtual hardware aka DEBBs). Results of the workload simulationpower usage and air throughput -are written to the Database (step 3), ready to be processes by the CFD simulation/solver.

The Database is responsible for accessing, managing and updating data: The CFD (Computational Fluid Dynamics) Solver is directly integrated into the COVISE workflow and enables to simulate and analyze complex heat flow (and dissipation) processes and their consequences on flow guiding structures, such as compute-building blocks (DEBBs) in data Centres. For this purpose a heat flow model defined by partial differential equations is defined. CFD solvers are using this model to calculate and simulate the interaction of liquids and gases with surfaces defined by boundary conditions and parameters (step 5). The results of a simulation are passed over to Simulation Workflow/COVISE (step 6).

The Metric Calculator is responsible for the assessment of the simulation results. Based on metrics identified and defined in D5.1, it assesses energyefficiency and heat-efficiency of building blocks (DEBBs). The calculation itself is based on data/metrics that are retrieved from the Database (step 9). Results of the calculation are written back (step 10) into the Database, to be retrieved and visualized by CoolEmAll Web GUI and in particular MOP GUI (step 11).

The CoolEmAll Web GUI provides web based GUI environment, integrating MOP GUI, COVISE GUI, DCWoRMS GUI and other, described below.

The MOP GUI (Module Operation Platform GUI), as described in [D4.1], delivers graphical user interfaces to support users monitoring project test bed, watching results of test bed experiments and simulated experiments (simulation results) and comparing them with each other. These GUI interfaces includes a web client and mobile access enriched with advanced visualisation. To present simulated experiment results (step 11), MOP GUI visualizes DEBB surfaces along with data stored in the Database, containing workload simulation results, CFD simulation results limited to temperature-and airflow history for particular sample points on object surfaces, and heat-and energy-efficiency metrics assessing experiment result.

The COVISE GUI presents entire simulation results of CFD-simulation, visualizing air flow across all building blocks (DEBBs). It enables interaction with the simulation, allowing to interactively change the simulation parameters that affects position (arrangement) of objects.

The DCWoRMS GUI allows users to establish the simulation environment parameters starting from selection of used resources and workloads through specification of application profiles up to definition of evaluated management policies. After the simulation is completed it enables review of generated results.

Detailed description of these components and their interfaces is provided in section 4.

SVD Toolkit Components

In this section we provide a description, in subchapters, of the different building blocks previously mentioned in the architecture overview, as well as the interfaces between them.

Data Center workload and resource management simulator

Data Center workload and resource management simulator (DCWoRMS) is a simulation tool based on GSSIM framework [GSSIM] developed by PSNC. GSSIM provides an automated tool for experimental studies of various resource management and scheduling policies in distributed computing systems. It achieves this through a flexible design of architecture and interactions between scheduling components, a possibility of plugging scheduling algorithms into the simulated environment, modeling synthetic workloads and adopting real traces in popular formats. DCWoRMS extends its basic functionality and adds additional features on top of it. They enable flexible and extensible configuration of the computing infrastructure topology both on logical and physical level. Energy aspects and virtualization technologies could thus be added to the simulation as well as several other features.

DCWoRMS architecture

The following figure presents the overall architecture of the simulation tool. In general, input data for the DCWoRMS consist of a description of workload and resources. Input data can be read from real traces (for details see sections below) or generated using the generator module. However, the key elements of the presented architecture are plugins. They allow a researcher to configure and adapt the simulation framework to his/her experiment scenario 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 tool. Due to a modular and plug-able architecture DCWoRMS enables adapting it to specific resource management problems and users' requirements.

Workload modeling

Experiments performed in GSSIM require a description of applications that will be scheduled during the simulation. As a basic description, GSSIM uses files in the Standard Workload Format (SWF) [SWF] or its extension Grid Workload Format (GWF) [GWF]. In addition to the SWF file, some more detailed description of a job and task can be provided in an additional 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. In addition, DCWoRMS enhances GSSIM and enables reading traces from real resource management systems like SLURM DCWoRMS provides user flexibility in defining the application model. 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 between jobs. Moreover, GSSIM is able to handle rigid and moldable jobs, as well as pre-emptive jobs. Each job may consist of one or more tasks. Thus, if preceding constraints are defined, a job may be a whole workflow. Moreover, tasks can be seen as a group of processes. This form of representation allows users to define a wide range of workloads: HPC (long jobs, cpu-intensive, hard to migrate) or web service (short requests) as well as typical data centre workloads using virtualization technique.

A summary of the workload management is shown in Figure 4-2 The resource description provides a structure and parameters of available resources. Flexible resource definition allows modeling 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 form 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. Due to an extensible description, users are able to define a number of experiment-specific and visionary characteristics. Moreover with every component, a specific profile can be associated that determines, among others, power, thermal and air throughput properties. The energy estimation plugin can be bundled with each resource.

Scheduling entities allow providing data related to the queuing system characteristics. Thus, information about available queues, resources assigned to them and their parameters like priority, availability of AR mechanism etc. can be defined. Moreover, allocation policy strategy for each scheduling level can be introduced in form of the reference to an appropriate plugin.

In this way, the DCWoRMS allows simulating a wide scope of physical and logical architectural patterns that may span from a single computing resource up to whole data centres or geographically distributed grids and clouds. In particular, it supports simulating complex distributed architectures containing models of the whole data centres, 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.

The logical architecture of distributed systems may assume centralized control of resources in fully distributed models. Moreover, the DCWoRMS allows building a hierarchy of local schedulers corresponding to the hierarchy of resource components over which the task may be distributed (e.g. clusters and compute nodes).

Application performance modeling

GSSIM also provides means to include complex and specific application performance models during simulations. These models can be plugged into the simulation environment through a dedicated API. Implementation of this plugin allows researchers to introduce specific ways of calculating task execution time.

The number of parameters including:

-task length (number of CPU instructions)

-task requirements -detailed description of allocated resources (processor type and parameters, available memory)

-input data size -network parameters can be applied to specify the execution time of a task. Using 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.

Simulation of energy efficiency

The DCWoRMS allows researchers to take into account energy efficiency and thermal issues in distributed computing experiments. To this end appropriate models and profiles must be used. In general, the main goal of the models is to emulate the behavior of the real computing resources, while profiles support models by providing required data. 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 The following subsections present the general idea behind the energy-efficiency simulations.

Power management concept

The DCWoRMS provides a functionality to define the energy efficiency of resources, dependency of energy consumption on resource load and specific applications, and to manage power modes of resources. Furthermore, it extends the energy management concept presented in GSSIM [GSSIM_Energy] by proposing a much more granular approach with the possibility of plugging energy consumption models and profiles into each resource level.

Power profile

Power profiles allow introducing information about power usage of resources.

Depending on the accuracy of a model, users may provide additional information about power states which are supported by the resources, amounts of energy consumed in these states, as well as general power profiles that provide means to calculate the total energy consumed by the resource during runtime. The above parameter categories may be defined for each element of a computing resource system. It is possible to define any number of new, resource specific, states, for example so called P-states, in which processor can operate.

Energy consumption model

The main goal 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, the DCWoRMS can be used to verify a number of theoretical assumptions and develop new energy consumption models.

Relation between model and power profile is illustrated in Figure 4-4.

The energy estimation plugin calculates energy consumption based on information about the resources' power profile, resource utilization, and the application profile including energy consumption and heat production metrics. The 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.

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

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

-The 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-

Power management interface

The DCWoRMS provides interfaces, which allow scheduling plugins to collect detailed information about computing resource components and to change their power states. It is possible to perform various operations on the given resources, including dynamically changing the frequency level of a single processor, turning off unused resources etc. The activities performed with this interface find a reflection in total amount of energy consumed by the resource during simulation.

Air throughput management concept

The presence of an air throughput concept addresses the issue of resource aircooling 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.

Air throughput profile

The 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. An air throughput value can also express a fan rotation speed. In this way, associating the air throughput profile with the given computing resource, it is possible to describe mounted air-cooling devices.

Possibility of introducing additional parameters makes the air throughput description extensible for new specific characteristics.

Air throughput model

Similar 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 4-5. Accordingly, air flow estimations are based on detailed information about the involved resources, including their air throughput states. The DCWoRMS comes with the following predefined models. By default, air throughput estimations are performed according to the first one.

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

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

Air throughput management interface

The DCWoRMS delivers interfaces that provide access to the profile data, allows acquiring detailed information concerning current air throughput conditions and changes in air flow states. The availability of these interfaces support implementation of different cooling strategies.

Thermal management concept

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

Thermal profile

Thermal 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

Temperature estimation model

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

The proposed approach assumes some simplifications that ignore heating and cooling processes.

The following models are supported natively. By default, the static strategy is applied.

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

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

Thermal resource management interface

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

Simulation results

The output of each simulation consists of a number of statistics created to help in comparative evaluations of resource and workload management policies. They are represented in textual (plain and easy to process CSV format) as well as in graphical form and illustrate the results of experiment obtained for both simulated resources and workload. There is also opportunity to obtain accumulated statistics for a series of simulations which are computed using data generated by each simulation separately. The following subsections present details concerning generated data. As a result, statistics for each resource entity are represented in form of pairs <timestamp, value> that allows tracking their changes over time. Moreover, for each characteristic the mean values are also calculated. Finally, all measurements can be visualized in form of the linear charts that facilitate the analysis of large volumes of data.

Workload Statistics

Workload statistics are represented as collection of measurements for every task that constitute the workload. Apart from basic characteristics, detailed information concerning generated schedule and task performance, like execution time, waiting time, etc. are gathered. Moreover, depending on the granularity of the application model, these values can be aggregated to represent the mean values for a set of tasks that belong to a single job (workflow). In addition to textual statistics, Gantt diagrams can be generated as well.

As a summary, general statistics are gathered also for the whole experiment in form of the measures (like mean, variance, min, max value, etc.) of the values calculated for both simulated resources and workload.

COVISE

As COVISE consists of several components that play together to create a visualisation. All components run in independent processes and communicate using messages and distributed shared memory. The main processes are the user interface (UI) called MapEditor, the Controller, the COVISE Request Broker (CRB) and the application modules. The local workstation normally is the one where COVISE is started. On this machine the user interface pops up and the Controller is started. All other processes are created from here, either using exec calls for local processes, or ssh and other remote invocation service calls for processes on remote computers. The user can include additional hosts into a session for remote module execution. On each machine a shared data space exists. The CRB administers the use of this shared data space in a database-like fashion. Simulations can be directly integrated into the COVISE workflow, including all necessary pre-and post-processing tasks. Together with a tight integration of all simulation steering and post-processing tasks in the virtual environment, this allows the creation of virtual test beds, offering rapid assessment and steering of high performance simulations. rotates the scene, the new transformation matrix is sent to the controller which in turn sends it to all other renderers. Of course, every user can request the master role.

COVISE offers a networked SOAP based API and is accessible by all components that can make use of Web Service based components. Thus it is quite convenient to integrate COVISE into existing infrastructures. All aspects of COVISE can be accessed remotely, and even the Rendering Results can be streamed to a local lightweight client.

Simulation Integration

COVISE offers a vast amount of reader modules for most of the important simulation codes. It has read modules for a lot of CFD codes and standard Formats including CGNS, NetCDS, ANSYS CFX / FLUENT and StarCD. Also some multiphysics codes are supported like LS-DYNA, COMSOL or Elmer. It is also possible to import data from other visualisation packages like EnSight or the VTK format used by ParaView.

Through its modular nature, it is easy to integrate running simulation services in COVISE. Those can be manipulated by a multitude of possibilities. Virtual interactors in the virtual environment allow an intuitive interface to boundary conditions and grid generation. Various menus with sliders and checkboxes can be used to also influence those. A 2D interface running on a TabletPC / PocketPC can be used to set specific numerical values. Last but not least, so called "Tangible Interfaces" consisting of a physical mockup of the simulation setup can be used to control mesh generation, boundary conditions and postprocessing. Successful integrations of simulation packages include StarCD, FENFLOSS, ANSYS CFX, OpenFOAM and Trans3D.

Usage in SVD

COVISE is a mature tool for visualisation that also includes hooks for geometry and grid generation as well as linking directly to various simulation codes. This functionality is proven using several in-house and commercial codes, including ANSYS CFX and StarCD. There is also a limited support for OpenFOAM in place. COVISE has proven to tackle the airflow computation of a data centre and its modular approach makes it easy to include new simulation codes in the workflow. Its extensive SOAP API allows steering COVISE from other components enabling it to fit easily in all emerging Web Service oriented infrastructures. The remote rendering capabilities allow using COVISE on a multitude of devices, including mobile platforms. COVISE already includes a grid generator for feeding an airflow computation of a data centre that could be extended for SVD purposes. With its AR capabilities, it is possible to verify the simulation results directly at the rack by overlaying measurements with a rendering of the simulation results. COVISE also sports a multitude of unusual input devices like Tangible Interfaces and 3D interaction devices. Its ability to run on the desktop and in VR environments for single users and collaboratively rounds up the COVISE profile, making it very suitable for inclusion in the final SVD. As it is developed by HLRS, full access to the source code is available and it will be easy to extend COVISE if needed features should be amiss.

Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 37 / 51

CFD Simulation

As described in 2.1.3, a CFD simulation consists of seven different steps which will be further detailed in the following subsections. Most of the components will be modelled as COVISE Modules which allows defining and executing the whole workflow. Data is passed from one module to the other automatically and data conversion is carried out as needed, even if the different processing steps run on physically distributed machines, such as Pre-and Post-Processing servers, Supercomputers, Visualisation workstations or clusters.

Geometry generation

DEBB Definition files define the hierarchy, geometric shape and the position of the all relevant geometric entities, such as server rooms, cooling components, racks, servers and so on. The Geometry generation step parses these files, extracts all relevant info and merges the individual geometry files of the individual components into one overall dataset for the next step. Geometry definition will be possible in two ways:

1. A simple box type modelling where components can be composed from an arbitrary number of boxes where the size of each box cannot be smaller than the discretisation of the computational mesh 2. Each component is modelled as STL files containing any number of patches. A name must be assigned to each of these patches which allows to reference them in order to assign boundary conditions.

Grid Generation

Two types of grid generation modules will be developed.

Box type meshes will be automatically meshed by a custom grid generator which creates an unstructured grid, consisting of hexahedron cells only.

Meshes for STL geometry will be created using SnappyHexMesh from OpenFOAM. This also creates an unstructured grid consisting of mostly hexahedron cells but between the surface mesh and different mesh resolutions, it adds Polyhedron cells.

Definition of boundary conditions

The definition of boundary conditions will not be modeled as a separate module but it will be carried out directly by the grid generation module.

Global boundary conditions such as initial temperature and velocity field can be specified as Parameters of the module. Other parameters such as the air vent velocities or power consumption of a certain node or rack will be read from the MOP Database. This allows simulating current conditions by accessing life measurements as well as simulated conditions as defined by the workload simulation which will also store the relevant parameters in the MOP database.

Domain decomposition

In order to carry out parallel simulations on todays distributed memory HPC systems, the computational mesh needs to be split into smaller parts, one for each compute node. Depending on the solver, this process is either an integral part of the solver itself or it is modeled as a separate COVISE module.

When using ANSYS CFX as the solver, domain decomposition is carried out by the solver itself, CFX does not support reading pre partitioned meshes.

In case of FENFLOSS, there is an existing COVISE module based on the METIS graph partitioning library. This could be extended to support additional boundary conditions and thus reused within CoolEmAll

In the final implementation within CoolEmAll, it is intended to use the open source simulation framework OpenFOAM to do the simulation. Therefore, preferably the parallel version of the OpenFOAM domain decomposition will be integrated as a module within COVISE.

Simulation

For a first prototype, we will integrate ANSYS CFX as solver within the SVD toolkit. Optionally, the CFD code FENFLOSS could be used which has much faster startup times and thus would provide quicker feedback for initial tests and simple CFD studies. In the final Version of the SVD Toolkit we will additionally support OpenFOAM as a solver. This approach makes sure the architecture can easily be extended by new types of solvers in the future and it will allow us to jump start with the development by reusing many existing components.

Post processing

Existing COVISE post processing modules can be reused to interactively extract data, compute particle traces and visualize 3D flow phenomena. An additional post processing module will be developed which extract measurement values as defined in the DEBB description. Those values will be stored in the MOP database for further visualisation in the SVD GUI and For the Aggregator to compute Green metrics to evaluate the performance of the overall system.

Rendering

Direct 3D Rendering with COVISE Virtual Reality environment renderer allows interactive in depth analysis of the 3D Air Flow for engineers to optimize the data centre during the planning phase or for modifications. During the operational phase the 3D Rendering will be omitted and only key values will be extracted and presented in the SVD GUI. smaller than the discretisation of the computational mesh 2. Each component is modelled as STL files containing any number of patches. A name must be assigned to each of these patches which allow referencing them in order to assign boundary conditions.

(b) The PLMXML file, describing DEBB hierarchy, contains for each object/shape a corresponding reference to its technical description, DEBB Component, describing its manufacturer and model in a CIM based format. This allows a workload scheduler to identify the node type being selected for workload execution and correlate it with its power-usage profile. The entire XSD schema for specification of DEBB composition is provided in D3.2.

(c1) The PLMXML file contains also reference to the power-profile, describing for each load level of a particular component type (model and manufacturer), its corresponding power-usage. This allows assessing power-usage of workload being executed on particular component types (node-types).

(c2) In addition to the power-profile, PLMXML file contains also air-throughput profile, stating air-throughput of FANs for different levels.

The detailed formal specification of DEBB models can be found in [D3.2].

DEBB Repository

As mentioned, the DEBB repository contains formal description of DEBBs required by workload-and CFD-simulations. The formal specification of DEBBs is described in [D3.2], and contains the geometry data including position of objects, hardware power profile and air throughput profiles of DEBBs. There exist a number of SVN clients, capable to access SVN server (repository). Wikipedia provides overview on available SVN clients [SVN-Wiki]. The most used command line options are:

• svn checkout -to checkout a working directory from the svn server

• svn add -to add a new file or directory to repository

• svn update/up -to update local copy with files from SVN server.

• svn commit/ci -to recursively sends local changes to the SVN server

• svn list -to display files in a directory for any given revision

• svn update -r <revision-number> -to check out specific revision

Application Models

An application has usually a complex behavior, with several phases with quite different characteristics. In the following we describe our two level approaches: Graph of tasks, tasks.

Graph of tasks

Due to a two level approach to the application modeling, the user has great flexibility in defining diverse workload models, which allows addressing various scheduling strategies. The proposed graph of tasks assumes that workloads may have various shapes and levels of complexity ranging from multiple independent jobs, through large-scale parallel applications, up to single tasks that require Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 42 / 51 single resources. That allows distinguishing several levels of information about incoming jobs. These levels are presented in Figure 5-3. We assume that there is a queue of jobs submitted to the resource manager. Then, each job consists of one or more tasks. If preceding constraints between tasks are defined, a job may constitute a whole workflow.

Tasks

Once constraints between tasks are expressed, what remains is the impact of each task on the system. For this, we follow the DNA approach, which describes, for one task, the impact of this task on the resources that run it. This approach is described in more detail in [Ghislain].

Description of a task consists of a sequence of letters, each of them represent a resource consumption profile. Each letter describes a phase of the task. Phases are periods of time where the system is stable (load, network, memory) given a certain threshold. A letter of the alphabet characterizes the behavior of an application during the phase and is linked to values of the system during the phase. Applications are thus a succession of phases described as a succession of letters.

In the simplest version, one could consider that a phase is characterized by the most consumed resource. In this case there could be 4 letters corresponding to "CPU phase", "Memory phase", "Disk phase" and "Network phase". To improve precision, a letter could include more information. Such a letter could be in our case "60% CPU, 30%net, 10%mem, 0% other". Letters are obtained either by knowing the exact intrinsic of a task, or can be obtained by using traces of execution of this task. Letter number is not decided before the characterization of a task. It is obtained once each phase has been detected and matched with the others. A constant task will always have exactly one letters in this formalism.

These Application profiles are dependent on the exact hardware. They will be obtained on the reference hardware, and a translation layer between the reference hardware to the actual hardware is added. For really different architecture (like embedded systems and cluster servers for instance) an application profile needs to be created for each node-type.

Synthetic workloads

The main goal of synthetic workloads is to capture the behavior of real observed workloads and to characterize them at the desired level of detail. On the other hand, they are also commonly adopted to evaluate the system performance for the modified or completely theoretical workload models. Usage of synthetic workloads and their comparison to the real ones has been the subject of research for many years [Synthetic_workloads]. Today, several synthetic workload models have been proposed [Feitelson], [Downey] which are based on workload logs collected from large scale parallel systems in production use. In general, synthetic workload models use probability distributions to generate workload data. For now, various distributions have been studied to imitate the characteristics of the particular workload properties.

Within the CoolEmAll project, and therefore, within the SVD Toolkit, synthetic workloads will be used along with the logs from real systems. Hence, one could take into account a number of possible models describing the particular stream of tasks. To address this issue, a flexible workload generator tool can be used. It is provided together with GSSIM [GSSIM], and thus with the DCWoRMS. Nevertheless, it is an independent application that may be used separately.

The Workload generator provides standard SWF workloads as well as additional parameters in an auxiliary file (in the XML format). All elements of the workload can be defined, beginning from a number of jobs/tasks, task arrival time, task runtime, through task resource requirements, such as requested number of CPUs, up to user's preferences and task execution time or preceding constraints. Each parameter can be described by standard statistical attributes, such as mean, minimum, maximum, standard deviation, and may have predefined probabilistic distribution, e.g. normal or constant.

To create synthetic workloads which are similar to real ones, it is possible to define dependencies between any two parameters in a configuration file. Exact values can be replaced by the dependency in a form of a mathematical expression which allows to use basic operators like +,-,*, /, (,). In addition to parameter dependencies, researchers can define parameters that have different probability distributions at different time periods. This feature allows to reflect the natural changes of tasks' parameter distributions at certain time or, in other words, to model daily cycles. For instance, tasks which are submitted in night hours may be longer than tasks submitted during a day time.

Another feature of the workload generator that allows defining more natural workloads is the use of multiple distributions for different parts of a workload. It is possible to define for a single parameter a number of distributions which describes only some percentage of generated values. For example, 30% of tasks will require 10 CPUs and the remaining 70% will require 5 CPUs.

MOP Database

As mentioned in section 3.2, in addition to monitoring data, the MOP Database can be reused to store also workload-data and extracts of CFD simulation results. However, the actual usage of the MOP Database depends on its capability to process/update the required amount of data produced by simulation results; this need to be validated first. In this section we describe functionality and interfaces of the MOP Database.

Functionality

In scope of the SVD, the MOP Database, is responsible for storing, accessing, managing and updating: (a) workload simulation results (air throughput and power dissipation) updated by "the Data Centre Workload and Resource Management Simulator", (b) CFD simulation results containing temperature history for particular sample points, and (c) energy-and heat-aware metrics assessing simulation results. As described in [D4.1], the MOP Database (also called Storage) is subscribed to particular topics and stores incoming data consisting of key-value pairs in the local round robin database, allowing the creation of time-series. In order to import data into the MOP Database, the TIMaCS framework (MOP Database is part of it) offers socket based data importers. Stored data can be retrieved by system administrators and by components analyzing data history, such as the Metric Calculator or the MOP GUI. For this purpose, the TIMaCS monitoring framework provides an API allowing retrieving stored monitoring data using RPC based clients.

Interfaces

As specified in the TIMaCS manual [TIMaCS-Man], the database exposes several methods via RPC that can be called to retrieve and store data. All database instances are aware of the hierarchy and forward requests for data that is not available locally to remote database instances. To query the database via • Etc.

All retrieved Values are in valid Python notation and can be transformed via the Python eval() function into normal Python objects. This simplifies integration of database operations with CoolEmAll functionality.

Direct RPC Client

Tool (direct_rpc_client.py) implements API calls mentioned above and can be used to retrieve the time, value pairs and other information from the metric database. The metric database holds the last (most recent) metric supplied by a particular node and stores time, value pairs in a time series database. The metric database also handles log data that is put into a log database. Examples on how to query the database is described in the TIMaCS Manual [TIMaCS-Man].

CoolEmAll Web GUI

There will be a common Web based GUI which serves as framework for all the components in the SVD Toolkit. All components will provide Web user interfaces which will be integrated in the CoolEmAll Web GUI. The COVISE Visualisation framework provides immersive Virtual Reality user interfaces for engineers to interactively analyze the 3D flow feature as well as tangible interfaces described in 5.5.1. The Workload Simulation GUI will be integrated into the CoolEmAll Web GUI and is described in 5.5.2. The same applies to the MOP GUI described in 5.5.3.

CFD Simulation GUI

Some use cases do not require interactive visualisation, in those cases there will be no GUI for the simulation but it will run in batch mode only. In other use cases, interactive visualisation of 3D CFD results is required and therefore the user will have the full COVISE user interface which includes a desktop rendering system, an immersive Virtual Reality GUI as well as a multitouch interface which can be used to provide a tangible interface to position racks in a server room. Within these GUIs, the engineer can interactively create cuts through the dataset, extract iso-surfaces and start particle traces in order to detect hot spots and modify the placement of racks, walls or air cooling components until an optimal airflow through the server room is achieved.

Workload Simulation GUI

As mentioned previously, the DCWoRMS is provided as a part of SVD Toolkit. DEBB, workload and application profiles repositories and to choose the proper models that will be used during the simulation phase. In addition, users can determine the load of resources according to various statistical parameters and probability distributions. Moreover, the DCWoRMS allows browsing a list of available workload and resource management policies that can easily be exchanged between different experiments. The output of each simulation consists of a set of statistics that are written into the Database. However, in case of independent workload simulations, the results of experiments can also be provided both in textual (standard and easy to parse CSV file format) and graphical (charts) way.

MOP GUI

As noted in SVD Toolkit Architecture Overview, MOP GUI will be used in the SVD Toolkit to visualize 3D textured geometries from DEBB models along with data from the MOP Database. As both, real data obtained from measurements (e.g. temperatures, system load) and simulated data from CFD and Workload Simulation will be stored in the database, both of them will be displayed in the MOP GUI which will be integrated in the CoolEmAll Web GUI. The available data stored in the database will be visualized in MOP GUI in two forms: color maps on top of 3D models and 2D charts.

The detailed architecture of MOP GUI was defined in [D4.1]. It also defined use cases which are still valid in scope of the SVD Toolkit. Use case UC2.2 (Historical data browsing) relates to browsing the historical data from simulation outputs and use case UC 2.1 (Virtual Thermal Camera) relates to online monitoring of the simulation outputs incrementally updated in the database. The later use case is considered optional as it depends on implementation details of the simulations.

CFD Solvers and Visualisation components

In a first prototype, we will use ANSYS CFX to carry out the CFD simulation as we can thus reuse a lot of existing components but throughout the project CFX will be replaced by the Open Source simulation framework OpenFOAM in order to be independent of commercial licensees and in order to use SnappyHexMesh as an automatic grid generation tool for complex CAD geometries of racks, servers and nodes which cannot be modeled by the existing grid generator for server rooms in COVISE.

MOP GUI will be implemented as an online Web service consisting of chart and 3D views visualizing current and historical state of a data centre. The first view will be built in-house using Dojo Toolkit Vitrall is a tool which enables efficient and easy integration of Web interfaces and 3D visualisation. It is a distributed visualisation system designed to efficiently utilize multi-GPU server installations. Vitrall can be used in collaborative environments, where many users can simultaneously interact in real-time, share or modify virtual 3D models over the Internet, as the processing part is performed completely on the remote side close to the data sources. Moreover, Vitrall provides a general Java Script client that is supported in most modern desktop and mobile Web browsers. It also provides a dedicated client running on Android platform. The later is capable of utilizing the built-in sensors, such as accelerometers and magnetic field sensors, to enable more natural user interaction, e.g. changing the orientation of the viewpoint.

More architectural details of Vitrall Visualisation System can be found in [D4.1].

  ........................................................................................ 38 4.3.6 Post processing ................................................................................ 38 4.3.7 Rendering ......................................................................................... 38 5 External Interfaces and Required Input ......................................................... 39 5.1 DEBBs models ........................................................................................ 39 5.2 DEBB Repository .................................................................................... 40 5.3 Application Models .................................................................................. 41 5.3.1 Graph of tasks .................................................................................. 41 5.3.2 Tasks ................................................................................................ 42 5.3.3 Synthetic workloads ......................................................................... 43 5.4 MOP Database ....................................................................................... 44 5.4.1 Functionality ..................................................................................... 44 5.4.2 Interfaces ......................................................................................... 44 5.5 CoolEmAll Web GUI ............................................................................... 46 5.5.1 CFD Simulation GUI ......................................................................... 46 5.5.2 Workload Simulation GUI ................................................................. 46 5.5.3 MOP GUI .......................................................................................... 47 6 CFD Solvers and Visualisation components ................................................. 47 References .......................................................................................................... 49

Figure 2 - 1 :Figure 2 - 2 Figure 2 - 3 Figure 4 - 1 :Figure 5 - 1 :

 2122234151 Figure 2-1: Workload simulation phase ................................................................ 9 Figure 2-2 CFD Simulation ................................................................................. 12 Figure 2-3 Visualisation Workflow ....................................................................... 12 Figure 3-1: SVD Architecture: logical view .......................................................... 19 Figure 4-1: DCWoRMS architecture ................................................................... 23 Figure 4-2: Workload management concept ....................................................... 24

  must enable, as an initial usage phase, the description of datacentre building blocks on different granularity levels, which will be used later on by other tools of the toolkit (for monitoring, visualisation and simulation purposes). Those building blocks are known as Data center Efficiency Building Blocks (DEBBs) [D3.1][D3.2]. The different levels of DEBBs are: node level, node group level, rack level (ComputeBox1) and compute room level (ComputeBox2).

Figure 2

 2 Figure 2-1: Workload simulation phase

•

  Modify boundary conditions, e.g. change an inlet air temperature • Adapt decomposition • Apply Post-Processing

Figure 2

 2 Figure 2-2 CFD Simulation

Figure 2

 2 Figure 2-3 Visualisation Workflow

Figure 3 - 1 :

 31 Figure 3-1: SVD Architecture: logical view

  Repository allows storing, editing and accessing of files remotely, while ensuring consistency of several files belonging to the same version, representing the configuration for a specific experiment. It consists of a DEBB repository, a Workload repository, and an Application Profile repository. The DEBB repository includes a formal description of DEBBs, described in [D3.2]. A DEBB is Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 20 / 51 described by a hierarchy, geometry data of objects used for simulation and visualisation (including position and orientation of components), the specification of component types, and a hardware power and air-throughput profile. The Workload repository contains a description of the workloads, used by the Data Centre Workload and Resource Management Simulator.

  (a) workload simulation results (air throughput and power dissipation) updated by "Data Centre Workload and Resource Management Simulator" (step 3) and retrieved by Simulation Workflow/COVISE for the CFD simulation (step 4), (b) CFD simulation results (provided by COVISE in step 8) containing temperature history for particular sample points, and (c) energy-and heat-aware metrics provided by the Metric Calculator assessing simulation results. All the results of the simulations (workload and CFD) as well as the assessment of the simulation results are retrieved and visualized by the CoolEmAll Web GUI (and MOP GUI) (step 11).The Simulation Workflow COVISE (COllaborative VIsualisation and Simulation Environment) developed by HLRS, is an extensible distributed software environment capable to integrate simulations, post-processing and visualisation functionalities in a seamless manner. The CFD Solver performing CFD simulation is directly integrated into the COVISE workflow, including all necessary pre-and post-processing tasks. COVISE offers a networked SOAP based API and is accessible by all components that can make use of Web Service based components. In CoolEmAll, COVISE firstly retrieves simulation relevant data (step 4 in Figure3-1) from the DEBB repository (containing geometry data and position of objects) and from the Database (containing results from Data Center simulator -power usage and air throughput), passes over these data to the CFD Solver (step 5), receives results from the CFD Solver (step 6), post processes and visualizes simulation results allowing at the same time modification of certain parameters (step 7) such as the arrangement of objects. Results of the simulation are written back into the Database (step 8), while modified geometrical parameters and arrangement of objects are used to update Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 21 / 51 DEBBs (step 8), to be stored in the DEBB repository (step 12). Using COVISE, users can analyze their datasets intuitively and interactively in a fully immersive environment through state of the art visualisation techniques, including Volume rendering and fast sphere rendering.

Version 2

 2 Relationship to Module Operating PlatformIn scope of D4.1 [D4.1] we presented the architecture of the Module Operating platform (MOP), capable (a) to execute various workloads on CoolEmAll test beds for various configurations, (b) monitor experiments during their execution while storing monitoring values in MOP Database (also called Storage in D4.1), (c) assess experiments results using the Metrics Calculator (also called Aggregator in D4.1), (d) and visualizes outcomes of experiments with the MOP GUI. In scope of D4.1 we described requirements ([D4.1], section 3.4) on MOP architecture, demanding its reusability by the SVD toolkit. As a consequence the MOP GUI will be reused for visualisation of the experiment results. As the MOP GUI operates on top of Storage, we came to the conclusion also to reuse Storage of the MOP, simplifying reuse and integration of the MOP GUI in the SVD toolkit. However, the actual usage of the MOP Database depends on its capability to process/update the required amount of data produced by simulation results -that need to be validated.

Version

Figure

  Figure 4-1: DCWoRMS architecture

  [SLURM] and Torque [TORQUE]. Further, the simulator is complemented with an Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 24 / 51 advanced workload generator tool that allows creating synthetic workloads.

Figure

  Figure 4-2: Workload management concept

Version

  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 Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 27 / 51 dedicated interfaces, which allow them to collect detailed information about computing resource components and to affect their behavior.

Version

Figure

  Figure 4-4: Energy consumption modeling

Figure

  Figure 4-5: Air throughput modeling

Version

Figure 4 -

 4 Figure 4-6 summarizes relation between model and profile and input data.

Figure

  Figure 4-6: Temperature estimation model

FigureA

  Figure 4-7: Statistics measures

  stated in [D2.1] COVISE stands for COllaborative VIsualisation and Simulation Environment. It is an extensible distributed software environment to integrate simulations, post-processing and visualisation functionalities in a seamless manner. From the beginning COVISE was designed for collaborative working, allowing engineers and scientists to work distributed on a network infrastructure. In COVISE, an application is divided into several processing steps, which are represented by COVISE modules. These modules, being implemented as separate processes, can be arbitrarily spread across different heterogeneous machine platforms. Major emphasis was put on the usage of high performance infrastructures such as parallel and vector computers and fast networks and support for collaborative working environments. The COVISE rendering module COVER supports Virtual Environments ranging from workbenches over Power walls, curved screens up to full domes or CAVEs and head mounted displays. The users can thus analyse their datasets intuitively in a fully immersive environment through state of the art visualisation techniques, including Volume rendering and fast sphere rendering. Physical prototypes or experiments can be included into the analysis process through Augmented Reality techniques. COVISE runs on all important platforms, the most important being Microsoft Windows, various Linux distributions and MacOS X Intel and PPC. COVISE is free of charge for academic use, for commercial exploitation a commercial license is available, including support and maintenance. A commercial COVISE Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 34 / 51 license starts at arround €8000.

Figure 4 - 8 :

 48 Figure 4-8: COVISE distributed architecture

Version

Figure 4 - 9 :

 49 Figure 4-9: Simulation coupling with COVISE

Version

Version

  This section describes the external interfaces of the SVD Toolkit, both towards the end user and with other CoolEmAll components, as well as the required input from external CoolEmAll components, presented in Figure5-1.

Figure 5 - 1 :

 51 Figure 5-1: External interfaces and required input

For

  the implementation of the DEBB repository, we decided on Apache Subversion (abbreviated SVN)[SVN]. Apache Subversion is an open source versioning and revision control system used to maintain current and historical versions of files such as source code, web pages, and documentation. In CoolEmAll, SVN will enable storing, updating and accessing DEBB files remotely, while ensuring consistency of several files belonging to the same DEBB version (managed by SVN) representing the configuration of an experiment. SVN capability to maintain history of different versions enables SVD users to access different DEBB-and experiment configurations, while keeping consistency between various files belonging to the same DEBB or experiment configuration.The Architecture of Subversion is based on Client-server architecture, with a server that stores all versioned data/files in a central repository.

Figure 5 - 2 :

 52 Figure 5-2: SVN-Overview

Figure

  Figure 5-3: Workload model

Version

  For instance, dependency between a number of CPUs and memory used by jobs can be Version:

Version

  For this reason it accepts and generates files in appropriate formats. In general, performing experiments with the DCWoRMS requires establishing the simulation environment properties first. They include specification of input files, such as resource and workload/application models. The DCWoRMS offers intuitive GUI which guides user through this stage. It provides means to navigate through Version: 1.0 Author: Uwe Wössner Date: 15/10/2012 Page 47 / 51

  [DojoToolkit]. The later will be used to perform 3D visualisation of DEBB models and map selected metrics from MOP Database to color 3D models and will use PSNC's Vitrall Visualisation System Version:

Table 1 Requirements

 1

traceability ...................................................................... 18

Requirement Area General Requirement ID Requirement Object

	the execution of different workloads on the simulation.
	Facilitate		Use	1.1.	Use predefined 3D models	DEBB
	analysis	of	predefined	1
	energy-		building
	efficiency and	blocks	1.1.	Use predefined IT equipment	DEBB
	thermal impact		2	models
	in DC			1.1.	Use predefined energy and	DEBB
				3	thermodynamic profiles
			Enable	1.2.	Simulate thermal behaviour within	SVD
			simulation of	1	a node-group
			thermal
			behaviour on	1.2.	Simulate thermal behaviour within	SVD
			various levels	2	a rack
				1.2.	Simulate thermal behaviour within	SVD
				3	a container/server room
			Provide	1.3.	Intuitive	visualisation	of	SVD
			advanced	1	comprehensive data
			visualisation
			tools	1.3.	Enable	easy	control	of	SVD
				2	visualisations
				1.3.
				3
	Version: 1.0 Version: 1.0					Author: Uwe Wössner Author: Uwe Wössner
	Date: 15/10/2012 Date: 15/10/2012					Page 14 / 51 Page 15 / 51

Allow easy re-arranging building blocks SVD Calculate heat-related metrics

		analysis	1.5.	Provide fast simulations	SVD
			2
	Enable	Integrate	2.1.	Calculate	combined	energy	SVD
	common	simulation of	1	consumption of IT equipment
	analysis of IT	energy		and infrastructure
	and	consumption of
	infrastructure	IT equipment	2.1.	Model impact of IT equipment	SVD
	aspects	and other DC	2	on the whole infrastructure
		infrastructure
		Integrate	2.2.	Pass IT equipment simulation	SVD
		simulation of IT	1	results as an input to heat
		equipment		transfer simulations
		utilisation and
		heat transfer	2.2.
			2
			1.4.	Define	metrics	expressing	DEBB,
			1	classes of efficiency including	Metrics
				relation	between	energy
				efficiency and temperatures
			1.4.	Define metrics expressing heat	DEBB,
			2	distribution among IT equipment	Metrics
			1.4.	Calculate and visualise heat-	SVD,
			3	related metrics		Metrics
		Enable	1.5.	Enable easy modification of	SVD
		efficient	1	input data
		interactive
	Version: 1.0				Author: Uwe Wössner
	Date: 15/10/2012				Page 16 / 51

Include heat-related information in IT equipment simulations

						SVD
	Visualize	IT	2.3.	Visualize	IT	equipment
	equipment	1
	utilisation and
	thermal
	effects using
	single	user
	interface

utilisation and thermal effects using single user interface MOP, SVD Enable analysis of dynamic relations between load and energy- efficiency by accurate modeling management policies, workloads and applications

	Model	and	3.1.	Model and simulate basic models	SVD,
	simulate		1	of queuing systems	Policies
	management
	policies		3.1.
			2

Model and simulate policies in virtualised environments SVD, Policies 3.1. 3 Define energy-and thermal- aware workload management policies using

				3.2.	Model	and	simulate	HPC	SVD,
				3	workloads	Workloa
							ds
		Model	and	3.3.	Model and simulate various	SVD,
		simulate		1	classes of HPC applications and	Applicati
		applications		their impact on thermal issues	ons
					and energy efficiency
				3.3.	Model and simulate cloud	SVD,
				2	services and their impact on	Applicati
					thermal issues and energy	ons
					efficiency
		Calculate		3.4.	Define and calculate metrics	SVD,
		metrics		1	expressing dependency between	Metrics
		expressing			energy-efficiency and workload
		dependency
		between		3.4.	Define and calculate energy	SVD,
		energy-		2	efficiency metrics expressing	Metrics
		efficiency and		trade-offs between energy and
		workload			performance
	Validate and	Provide		4.1.	Rack-level	Comput
	verify	energy-		1			eBox1,
	simulation	efficient	IT				DEBB
	models	equipment
		blueprints		4.1.	Container/Server room-level	Comput
				2			eBox2,
							DEBB
		Provide		4.2.
		energy-		1			SVD,
		efficient	IT				Policies
		equipment					identified workload
		prototypes		properties (workload-classes) to
					manage thermal impact
		Model	and	3.2.	Model and simulate workload	SVD,
		simulate		1	variability and its impact on	Workloa
		workloads			thermal issues and energy	ds
					efficiency
				3.2.	Model and simulate cloud	SVD,
				2	workloads	Workloa
							ds
	Version: 1.0						Author: Uwe Wössner
	Date: 15/10/2012					Page 17 / 51

Node-group-level

						Comput
						eBox1,
						RECS
		4.2.	Rack-level			Comput
		2				eBox1,
						RECS
	Enable	4.3.	Enable	efficient	collecting	MOP,
	efficient	1	metrics values from multiple	RECS
	monitoring		sources
	and control of
	real	4.3.	Deliver fine grained and frequent	MOP
	infrastructure	2	information about power usage
			of IT equipment
	Version: 1.0				Author: Uwe Wössner
	Date: 15/10/2012				Page 18 / 51

Table 1 Requirements traceability

 1

RPC, a connection must be opened to only one of the database instances. The query that would locally correspond to the call of a function, method (arg1, arg2, key3=arg3...) is sent serialized as plain text in the form method arg1 arg2 key3=arg3... over the RPC channel. The database returns the results also as plain text that represents a valid Python object. This text can be deserialized via the appropriate method to construct a local Python object.

Callable API functions:

• getHostNames(group_path): List all hosts for which metrics are stored.

• getLastMetricsByHostName(group_path, host_name): Return a MetricSet object that is a list of many Metric objects that are attributed to host_name. Note that the Metric objects do just contain one time-value pair, the most recent one! Other time, value records could be retrieved with getRecordsByMetricName.

• getLastMetricByMetricName(group_path, host_name, metric_name): Retrieve the metric specified by host_name and metric_name. The metric contains the last time and value recorded.

• getLastSeen(group_path, host_name): Return the last_seen timestamp and age for a host.

• getMetricNames(group_path, host_name): List all metric names that are stored for a particular host name.

• getRecordsByMetricName(group_path, host_name, metric_name, start_s, end_s, nsteps, step_s): Return a list that contains record objects. Each record has two attributes time_ns (time in 10E-9 seconds) and value. The argument start_s in seconds specifies the earliest record to be returned.

No records newer than end_s (in seconds) are returned. Finally nsteps defines the number of steps (data points) to return. Like step_s this will lead to averaging for numeric data. The argument step_s gives the minimum time between two consecutive records. This method returns a list containing records.

• getSummary(group_path, path): Returns A "directory" listing of a path inside the file system serialized metric database.

• getTimeSeriesType(group_path, host_name, metric_name): Return the type of time-series stored for a metric on a host, i.e. it's class name. The returned string contains the class name of the time series for the metric and is either "RRD" or "LOG".

• findWhereMetric(group_path, metric_name, metric_attr, condition, value, recurse=false): Return hosts for which the given metric's attribute fulfills a particular condition. This method is implemented as a fast look-up that only scans the in-memory data and avoids expensive disk operations.