Révision 68fb6bef papers/2014/kwapi/cloudam2014.tex
b/papers/2014/kwapi/cloudam2014.tex | ||
---|---|---|
66 | 66 |
|
67 | 67 |
Although from a cost perspective, monitoring the power consumption of only part of deployed equipments is sound, it prevents one from capturing certain nuances of the infrastructure. Previous work has 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. 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 can allow for further improvements in energy efficiency. Monitoring a great number of nodes, however, require the design of an efficient infrastructure for collecting and processing the power consumption data. |
68 | 68 |
|
69 |
This paper describes the design and architecture of a generic and flexible framework, termed as Kilowatt API (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/}. Ceilometer is an OpenStack component conceived provide a framework to collect a large range o metrics for metering purposes\footnote{https://wiki.openstack.org/wiki/Ceilometer}. In this work we describe how Kwapi has been integrated into Ceilometer. With the increasing use of Ceilometer as the 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. |
|
69 |
This paper describes the design and architecture of a generic and flexible framework, termed as Kilowatt API (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/}. Ceilometer is an OpenStack component conceived provide a framework to collect a large range of metrics for metering purposes\footnote{https://wiki.openstack.org/wiki/Ceilometer}. In this work we describe how Kwapi has been integrated into Ceilometer. With the increasing use of Ceilometer as the 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.
|
|
70 | 70 |
|
71 |
The remaining part of this paper is organised as follows. Section~\ref{sec:related_work} describes related work, Section~\ref{sec:architecture} presents the requirements and introduces the Kwapi architecture. Section~\ref{sec:performance} discusses experimental results measuring the throughput of drivers and plug-ins and Section~\ref{sec:conclusion} concludes the paper. |
|
71 |
The remaining part of this paper is organised as follows. Section~\ref{sec:related_work} describes background and related work, Section~\ref{sec:architecture} presents the requirements and introduces the Kwapi architecture. Section~\ref{sec:performance} discusses experimental results measuring the throughput of drivers and plug-ins and Section~\ref{sec:conclusion} concludes the paper.
|
|
72 | 72 |
|
73 | 73 |
% ---------------------------------------------------------------------------------------- |
74 | 74 |
|
... | ... | |
82 | 82 |
Ceilometer --- whose logical architecture\footnote{http://docs.openstack.org/developer/ceilometer/architecture.html} is depicted in Fugure~\ref{fig:arch_ceilometer} --- is OpenStack's framework for collecting performance metrics and information on resource consumption. As of writing, it allows for data collection in three ways: |
83 | 83 |
|
84 | 84 |
\begin{itemize} |
85 |
\item \textbf{Bus listener agent}, which picks events on the Oslo notification bus and turns them into Ceilometer samples (\textit{e.g.} cumulative type, gauge or delta) that can be stored into the database or provided to an external system via the publishing pipeline. |
|
86 |
\item \textbf{Push agents}, more intrusive, that consist in deploying agents on the monitored nodes to push the data remotely to be taken by the collector. |
|
85 |
\item \textbf{Bus listener agent}, which picks events on the Oslo notification bus and turns them into Ceilometer samples (\textit{e.g.} cumulative type, gauge or delta) that can then be stored into the database or provided to an external system via the publishing pipeline. |
|
86 |
|
|
87 |
\item \textbf{Push agents}, more intrusive, consist in deploying agents on the monitored nodes to push the data remotely to be taken by the collector. |
|
88 |
|
|
87 | 89 |
\item \textbf{Polling agents} that poll APIs or other tool to collect information. |
88 | 90 |
\end{itemize} |
89 | 91 |
|
... | ... | |
94 | 96 |
\label{fig:arch_ceilometer} |
95 | 97 |
\end{figure} |
96 | 98 |
|
97 |
The last two methods in fact depend on a combination of central agent, computer agents and collector. Whilst the compute agents run on nodes and retrieve information about resource usage related to a given virtual machine instance and a resource owner, the central agent, on the other hand, executes \textit{pollsters} on the management server to retrieve the data that is not tight to a particular instance. Pollsters are executed, for example, to poll resources by using an API or other method. The Ceilometer database can be queried via the Ceilometer API, and allows an external system to view the history of a resource's metrics. It also enables a system to set and receive alarms.
|
|
99 |
The last two methods depend on a combination of central agent, computer agents and collector. Whilst the compute agents run on nodes and retrieve information about resource usage related to a given virtual machine instance and a resource owner, the central agent on the other hand, executes \textit{pollsters} on the management server to retrieve data that is not linked to a particular instance. Pollsters are executed, for example, to poll resources by using an API or other method. The Ceilometer database can be queried via the Ceilometer API, and allows an external system to view the history of a resource's metrics. It also enables a system to set and receive alarms.
|
|
98 | 100 |
|
99 | 101 |
Metering messages can be signed using the \textit{hmac} module in Python's library, and a shared secret value can be provided in the configuration settings. The message signature is included in the message to be used for verification by the colector or by systems accessing the API. |
100 | 102 |
|
... | ... | |
204 | 206 |
|
205 | 207 |
\begin{figure*}[!htb] |
206 | 208 |
\center |
207 |
\includegraphics[width=0.9\linewidth]{figs/kwapi_interface.png}
|
|
209 |
\includegraphics[width=0.9\linewidth]{figs/graph_example.jpg}
|
|
208 | 210 |
\caption{Example of graph generated by the visualisation plug-in (4 monitored servers).} |
209 | 211 |
\label{fig:graph_example} |
210 | 212 |
\end{figure*} |
Formats disponibles : Unified diff