Run Time Environment (RTE)
This environment is responsible for the applications of the adaptation actions required to reduce the energy consumption of the Data Centre without affective the performance level of the applications running on it. It can be roughly split in three main software components, described in the followings.
Global Control Loop implementation
The Global Control Loop proactively identifies the service centre over-provisioned computing resources with the goal of putting them to low power states. It is based on techniques like: resource virtualisation, energy efficient resource provisioning, resource consolidation and dynamic power management. The Global Control Loop main implementation modules are the following: Context Monitoring Module, Context Analysis Module, Action Planning Module and Action Plan Enforcement Module.
Context Monitoring Module implemented functionality is to interact with the Context Accessing and Processing API (part of ESMI) using RMI (Remote Method Invocation) calls to update the local copy of the current EACM model ontology instance and to get adaptation knowledge from EPKB.
The Context Analysis Module implements the Global Control Loop adaptation methodology analysis phase referring to the evaluation of the low level GPIs/KPIs (such as servers’ loading values) for determining if adaptation actions planning is required. The evaluation of low level GPI/KPIs is implemented by means of reasoning techniques. The evaluation result is stored in the current EACM ontology instance and is used by the Context Analysis Module to calculate the context entropy value.
The Action Planning Module goal is to implement the Global Control Loop adaptation methodology planning phase aiming at determining the adaptation action plans that need to be executed. It has two main sub-modules: (i) Similar Context Identification Module – identifies similar context situations using clustering techniques and (ii) Adaptation Action plan Generation Module – constructs the adaptation action plans by means of reinforcement learning.
The Action Plan Enforcement Module executes the adaptation actions plans through the Infrastructure Access Module.
Local Control Loops implementation
The Local Control Loops are based on the ACPI standard which allows for dynamically changing the processor power states (C-states) and performance states (P-states) using low level operating systems calls. The main energy saving idea implemented by the local loops is to put the server CPU to Sleep State (C-3) when no workload is executed and oscillate between the CPU performances states (P-states) according to the workload characteristics when the CPU is in the Operating State (C-0). When deciding to change the P-State of the CPU, the Local Control Loops trade-off performance – energy by considering that in a higher P-State the CPU will consume more power while in a lower P-State, the CPU performance degradation will be higher. Two types of Local Control Loops have been implemented: a Fuzzy Logic based Local Control Loop and a Bio-inspired Local Control Loop. They are both installed on the service centre servers and can be dynamically activated or deactivated based on the suggestions received from the Design Time Environment (i.e. co-design methodology workload and energy consumption analysis).
The Fuzzy Logic Local Control Loop
The Fuzzy Logic based Local Control Loop tackles the CPU energy efficiency problem by using fuzzy sets and fuzzy functions to characterize the CPU current workload intensity and to determine the appropriate transitions of the CPU P-states. We have chosen fuzzy logic due to its ability to filter-out the noise and to progressively adapt to changes. The adaptation algorithm filters the situations in which the workload fluctuates for short periods of time because the costs of P-states transitions (in terms of consumed energy) can outweigh the benefit of the adaptation. It determines the membership of the workload level to a high or low fuzzy interval, and computes the value for a normalized control variable. The value of the control variable determines the dynamic frequency scaling action to be taken, as follows: if it is above 1, the CPU is transitioned in a higher P-State and if it is below -1 the CPU is transitioned in a lower P-State.
The Bio-inspired Local Control Loop
Bio-inspired Local Control Loop tackles the CPU energy efficiency problem using models, techniques and algorithms inspired from the human immune system. The loop implements the following human immune system models: (i) an antigen inspired model to represent the server current energy/performance data, (ii) an immune cell inspired model to represent associations between a detector (a server non optimal energy/performance state) and an effector (an adaptation action used to bring the server in an optimal energy/performance state) and (iii) an immune memory inspired model to represent the adaptation/optimization knowledge base (stores all the immune cells determined during the adaptation processes). The loop implements the following human immune system techniques: (i) self/non-self classification to determine if the current antigen represents an optimal/non optimal energy performance state, (ii) negative selection to create the detectors and effectors for the antigens classified as non-self and (iii) mutation based clonal selection to determine the adaptation actions (dynamic frequency scaling) to be executed for bringing the server in an optimal energy consumption state.
Storage Advanced Management Controller for Energy Efficiency (SAMCEE)
The Storage Advanced Management Controller for Energy Efficiency (SAMCEE) manages application data with the goal of reducing the energy consumed by the storage subsystem, while maintaining a specified QoS level. It includes two separate controllers: one for disk mode and another for file placement.
The disk mode control attempts to select the most energy efficient disk (acoustic AMM) mode for a given device's access patterns. The file placement controller includes a backend Network Attached Storage (NAS) server that manages the backend files and exports the managed files and directories via NFS. Application level files are split into smaller chunks, and each chunk is placed separately on a selected device. The selection of the most appropriate location for chunk placement is based on device and chunk ranking, calculated according to usage centric energy efficiency criteria for storage. The disks for chunk placement are selected among the top ranking devices as computed at a given point in time. Data consolidation and high device usage is achieved by giving high weight to the capacity energy efficiency metric. Consolidating the data into a small number of active devices allows to put unallocated disks in stand-by mode and thus saves energy. High device usage allows to leverage the disk access optimization and to select a proper acoustic mode. The SAMCEE main sub-components are:
a) The two controllers for file placement and acoustic mode selection
described above
b) The FUSE file splitter and file level statistics collection module
A file splitter and file level statistics collection mechanism was designed and developed using the user space file system framework FUSE. This module defines a mount point (exportable by NFS), and every user file stored under this mount point is managed, split into chunks and monitored for its read/write IOPS and throughput. This mechanism and information are used by SAMCEE for file placement control.
c) High level Application to file mapping agent module
The application to file mapping agent identifies and maps high level services and processes to storage file resources. It also sends to SAMCEE (via API calls or the EPKB database) annotations (high level indications) on application files, which may be used by SAMCEE in its file placement decision making and in aggregating power consumption for an application per its associated files .
d) Linux extension module
In order to obtain statistical data that is unavailable in current Linux OS versions, the Linux kernel was extended to collect the additional data items. Examples of the Linux patch code include extension of the Linux VFS layer to collect the portion of disk sequential accesses and the disk queue length, number of read/write I/Os per device and the average throughput.
The Linux patch writes the newly collected data to the standard diskstats pseudo-file, and this file is inspected and read by a special agent that manages the data. Information is collected for all Linux identified devices.
e) Python low level collection agent
In order to collect the data from a given set of devices (e.g., SATA disks) and communicate that information in a convenient manner, A Python perfAgent agent was designed and developed, which can be configured and accessed over a TCP socket in a convenient manner. Another agent – performanceService – persists the information into a mysql disk_perf table for further use.