Révision 5e8b7c49
b/papers/2014/kwapi/paper.tex | ||
---|---|---|
57 | 57 |
|
58 | 58 |
|
59 | 59 |
\begin{abstract} |
60 |
Although cloud computing has been transformational to the IT industry, it is built on large data centres that often consume massive amounts of electrical power. Efforts have been made to reduce the energy clouds consume, with certain data centres now approaching a \ac{PUE} factor of 1.08. While this is an incredible mark, it also means that the IT infrastructure accounts for a large part of the power consumed by a data centre. Hence, means to monitor and analyse how energy is spent have never been so crucial. Such monitoring is required not only for understanding how power is consumed, but also for assessing the impact of energy management policies. In this article, we draw lessons from experience on monitoring large-scale systems and introduce an energy monitoring software framework called \ac{KWAPI}. The framework --- whose architecture is scalable, extensible, and completely integrated into OpenStack --- supports several wattmeter devices, multiple measurement formats, and minimises communication overhead.
|
|
60 |
Although cloud computing has been transformational to the IT industry, it is built on large data centres that often consume massive amounts of electrical power. Efforts have been made to reduce the energy clouds consume, with certain data centres now approaching a \ac{PUE} factor of 1.08. While this is an incredible mark, it also means that the IT infrastructure accounts for a large part of the power consumed by a data centre. Hence, means to monitor and analyse how energy is spent have never been so crucial. Such monitoring is required not only for understanding how power is consumed, but also for assessing the impact of energy management policies. In this article, we draw lessons from experience on monitoring large-scale systems and introduce the energy monitoring software framework called \ac{KWAPI} able to deal with OpenStack clouds. The framework --- whose architecture is scalable, extensible, and completely integrated into OpenStack --- supports several wattmeter devices, multiple measurement formats, and minimises communication overhead.
|
|
61 | 61 |
\end{abstract} |
62 | 62 |
|
63 | 63 |
|
... | ... | |
75 | 75 |
|
76 | 76 |
From a cost perspective, monitoring the power consumption of only a small part of deployed equipments is sound but it prevents one from capturing important nuances of the infrastructure. Previous works have shown that as a computer cluster ages, certain components wear out, while others are replaced, leading to heterogeneous power consumption among nodes that were seemingly homogeneous \cite{DeanGoogleFailures:2008}. The difference between nodes that consume the least power and nodes that consume the most can reach 20\% \cite{MehdiHeterogeneous:2013}, which reinforces the idea that monitoring the consumption of the whole set of IT equipments is mandatory for exploring further improvements in energy efficiency, but also evaluate the impact of energy monitoring policies. Monitoring a great number of nodes, however, require the design of an efficient infrastructure for collecting and processing the power consumption data. |
77 | 77 |
|
78 |
This paper describes the design and architecture of a generic and flexible framework, termed as \ac{KWAPI}, that interfaces with OpenStack to provide it with power consumption information collected from multiple heterogeneous probes. OpenStack is a project that aims to provide ubiquitous open source cloud computing platform and is currently used by many corporations, researchers and global data centres\footnote{http://www.openstack.org/user-stories/}. We describe how \ac{KWAPI} has been integrated into Ceilometer; OpenStack's component conceived to provide a framework to collect a large range of metrics for metering purposes\footnote{https://wiki.openstack.org/wiki/Ceilometer}. With the increasing use of Ceilometer as the \textit{de facto} metering tool for OpenStack, we believe that such an integration of a power monitoring framework into OpenStack can be of great value to the research community and practitioners. |
|
78 |
This paper describes the design and architecture of a generic and flexible framework, termed as \ac{KWAPI}, that originally interfaces with OpenStack to provide it with power consumption information collected from multiple heterogeneous probes. OpenStack is a project that aims to provide ubiquitous open source cloud computing platform and is currently used by many corporations, researchers and global data centres\footnote{http://www.openstack.org/user-stories/}. We describe how \ac{KWAPI} has been integrated into Ceilometer; OpenStack's component conceived to provide a framework to collect a large range of metrics for metering purposes\footnote{https://wiki.openstack.org/wiki/Ceilometer}. With the increasing use of Ceilometer as the \textit{de facto} metering tool for OpenStack, we believe that such an integration of a power monitoring framework into OpenStack can be of great value to the research community and practitioners.
|
|
79 | 79 |
|
80 | 80 |
The remaining part of this paper is organised as follows. Section~\ref{sec:related_work} describes background and related work, whereas Section~\ref{sec:architecture} presents requirements for an energy monitoring framework and introduces the \ac{KWAPI} architecture. Section~\ref{sec:performance} discusses experimental results on measuring the throughput of \ac{KWAPI} drivers and plug-ins, and Section~\ref{sec:conclusion} concludes the paper. |
81 | 81 |
|
... | ... | |
110 | 110 |
The \textit{hmac} module of Python's library can be used for signing metering messages, and a shared secret value can be provided in the configuration settings. The collector and systems accessing the API use signatures included in the messages for verification. |
111 | 111 |
|
112 | 112 |
|
113 |
\subsection{Related Work} |
|
113 |
\subsection{Related Work on Energy Monitoring and Efficiency in Clouds}
|
|
114 | 114 |
|
115 | 115 |
Over the past years, several techniques have been provided to minimise the energy consumed by computing infrastructure. At the hardware level, for instance, processors are able to operate at multiple frequency and voltage levels, and the operating systems or resource managers can choose the level that matches the current workload \cite{LaszewskiDVFS:2009}. At the resource management level, several approaches are proposed, including resource consolidation \cite{BeloglazovOpenStack:2014} and rescheduling requests \cite{OrgerieSaveWatts:2008}, generally with the goal of switching off unused resources or setting them to low power consumption modes. Attempts have also been made to assess the power consumed by individual applications \cite{NoureddineThesis:2014}. |
116 | 116 |
|
... | ... | |
137 | 137 |
\label{fig:architecture} |
138 | 138 |
\end{figure*} |
139 | 139 |
|
140 |
The communication between the layers is handled by a bus, as explained in detail later. Data consumers can subscribe to receive information collected by drivers from multiple sites. Both drivers and consumers are easily extensible to support, respectively, several types of wattmeters and provide additional data processing services. A REST API is designed as a data consumer to provide a programming interface for developers and system administrators. In this work is used to interface with OpenStack by providing the information (\textit{i.e.} by polling monitored devices) required by a \textit{\ac{KWAPI} Pollster} to feed Ceilometer. |
|
140 |
The communication between the layers is handled by a bus, as explained in detail later. Data consumers can subscribe to receive information collected by drivers from multiple sites. Both drivers and consumers are easily extensible to support, respectively, several types of wattmeters and provide additional data processing services. A REST API is designed as a data consumer to provide a programming interface for developers and system administrators. In this work it is used to interface with OpenStack by providing the information (\textit{i.e.} by polling monitored devices) required by a \textit{\ac{KWAPI} Pollster} to feed Ceilometer.
|
|
141 | 141 |
|
142 | 142 |
The following sections provide more details about the main components of the KWAPI architecture and their relationship with OpenStack Ceilometer. |
143 | 143 |
|
... | ... | |
165 | 165 |
\item methodology applied to each measurement (\textit{e.g.} mean of several measurements, instantaneous values, and exponential moving averages). |
166 | 166 |
\end{itemize} |
167 | 167 |
|
168 |
Table \ref{tab:wattmeters} shows the characteristics of equipments we deployed and evaluated in our data centres.
|
|
168 |
Table \ref{tab:wattmeters} shows the characteristics of equipments we deployed and used with Kwapi in our Cloud infrastructures.
|
|
169 | 169 |
|
170 | 170 |
\begin{table} |
171 | 171 |
\centering |
... | ... | |
235 | 235 |
\section{Performance Evaluation} |
236 | 236 |
\label{sec:performance} |
237 | 237 |
|
238 |
This section provides results of a performance evaluation carried out in our testbed. The goal is not to compare publish/subscribe systems as such work has already been performed elsewhere \cite{EugsterSurvey:2003,FabretPS:2001}. The evaluation demonstrates that the framework serves well the needs of a large range of users of the Grid'5000 platform \cite{Grid5000} --- the infrastructure we use and where the framework is currently deployed as the means for collecting and providing energy consumption information to users.
|
|
238 |
This section provides results of a performance evaluation carried out in our testbed. The goal is not to compare publish/subscribe systems as such work has already been performed elsewhere \cite{EugsterSurvey:2003,FabretPS:2001}. The evaluation demonstrates that the framework serves well the needs of a large range of users of the Grid'5000 platform \cite{Grid5000} --- the infrastructure we use and where the Kwapi framework is currently deployed in production mode as the means for collecting and providing energy consumption information to users.
|
|
239 | 239 |
|
240 | 240 |
Firstly, we want to evaluate the CPU and network usage of a typical driver to observe the framework's throughput, since provisioning a large number of resources for monitoring purposes is not desirable. For this experiment we deployed the \ac{KWAPI} drivers and API on a machine with a Core 2 Duo P8770 2.53Ghz processor and 4GB of RAM. We considered: |
241 | 241 |
|
... | ... | |
305 | 305 |
\section{Conclusion} |
306 | 306 |
\label{sec:conclusion} |
307 | 307 |
|
308 |
In this paper, we described a framework for monitoring the power consumed by resources of a cloud data centre. Based on lessons learned by monitoring the power consumption of a large distributed infrastructure, we described the main user requirements and how they are met by the proposed architecture. The framework works in tandem with OpenStack's Ceilometer. Experimental results demonstrate that the overhead posed by the monitoring framework is small, allowing us to serve the users' monitoring needs of our infrastructure.
|
|
308 |
In this paper, we described the first framework (KWAPI) for monitoring the power consumed by resources of an Openstack cloud. Based on lessons learned on monitoring the power consumption of a large distributed infrastructure, we described the main user requirements and how they are met by the proposed architecture. The framework works in tandem with OpenStack's Ceilometer. Experimental results demonstrate that the overhead posed by the monitoring framework is small, allowing us to serve the users' monitoring needs of our large scale infrastructure.
|
|
309 | 309 |
|
310 | 310 |
As future work, we intend to explore means to increase the monitoring granularity and the number of measured devices by applying a hierarchy of plug-ins, and a stream processing system with guarantees on data processing \cite{Storm,S4} for processing streams of measurement tuples. |
311 | 311 |
|
Formats disponibles : Unified diff