Laboratoire de l'Informatique et du Parallélisme » XLcloud

\begin{abstract}

\end{abstract}

Cloud computing \cite{ArmbrustCloud:2009} has become a key building block in providing IT resources and services to organisations of all sizes. Amongst its claimed benefits, the most appealing derive from economies of scale and often include a pay-as-you-go business model, resource consolidation, elasticity, good availability, and wide geographical coverage. Despite the advantages when compared to other provisioning models, to serve customers with the resources they need Clouds often rely on large data centres that consume massive amounts of electrical power \cite{BaligaInternet:2011}.

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.

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. 

% ----------------------------------------------------------------------------------------

\label{sec:architecture}

Depending on the number of monitored devices and the frequency at which measurements are taken, wattmeters can generate a large amount of data, which requires storage capacity for further processing and analysis. Although storing and performing pre-processing locally in the monitored nodes if often an approach followed by certain management systems, such an approach poses a few challenges when measuring power consumption; it can impact on the CPU utilisation and hence influence in the power consumed by the nodes, and depending on the power management policy in place, unused nodes may be switched off or set to stand by mode to save energy. Centralised storage, on the other hand, allows for faster access and processing of data, but can generate more network traffic given that all measurements need to be transferred continuously over the network to be stored. Once stored in a central repository, this data can be easily retrieved by components like OpenStack's Ceilometer.

\item methodology applied to each measurement (\textit{e.g.} mean value between several measurements, instantaneous values, and exponential moving averages).

\end{itemize}

\begin{table}

\centering

\label{tab:wattmeters}

\begin{footnotesize}

\begin{tabular}{llcc}

\multirow{2}{18mm}{\textbf{Device Name}} & \multirow{2}{30mm}{\textbf{Interface}} & \multirow{2}{12mm}{\centering{\textbf{Refresh Time (s)}}} & \multirow{2}{10mm}{\centering{\textbf{Precision (W)}}}  \\

& & & \\

\toprule

\midrule

\midrule

OmegaWatt      & IrDA Serial               & 1    & 0.125 \\

\midrule

\midrule

Watts Up?      & Proprietary via USB       & 1    & 0.1 \\

\midrule

\label{fig:graph_example}

\end{figure}

\subsubsection{Internal communication bus}

Kwapi uses ZeroMQ\footnote{http://zeromq.org/}, a fast broker-less messaging framework, written in C++, where transmitters play the role of buffers. ZeroMQ supports a wide range of bus modes, including cross-thread communication, IPC, and TCP. Switching from one to another is straightforward. It also provides several design patterns such as publish/subscribe, and request/response. In our architecture, we use a publish/subscribe design pattern where drivers are publishers, and plug-ins are subscribers. Amongst them, one or more forwarders simply forward packets, and broadcast a packet to all plug-ins subscribed to receive information from a given probe. Thanks to the forwarders, the network usage is optimised because the packets generated by a driver are sent only once, regardless the number of plug-ins that listen to a probe. If a probe is not listened by any plug-in, its measurements are neither sent over the network nor to the first forwarder. The forwarders not only reduce dramatically the network usage, but allow to build flexible architectures, by bypassing network isolation problems, or doing load balancing.

\section{Conclusion}

\label{sec:conclusion}

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 \footnote{https://storm.incubator.apache.org}$^,$\footnote{http://incubator.apache.org/s4/} for processing sterams of measurement tuples.