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

%% paper.tex

%% V1.0

%% 05/07/2013

%% by François Rossigneux

\documentclass[conference]{IEEEtran}

\usepackage[utf8]{inputenc}

\usepackage[T1]{fontenc}

\usepackage{graphicx}

\usepackage{epstopdf} 

\ifCLASSOPTIONcompsoc

  \usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}

\else

  \usepackage[caption=false,font=footnotesize]{subfig}

\fi

\begin{document}

\title{Improving HPC support in OpenStack\\by introducing a resource reservation service}

\author{

  \IEEEauthorblockN{François Rossigneux}

  \IEEEauthorblockA{INRIA, Lyon, France\\

  Email: francois.rossigneux@inria.fr}

  \and

  \IEEEauthorblockN{Jean-Patrick Gelas}

  \IEEEauthorblockA{University of Lyon, France\\

  Email: jean-patrick.gelas@univ-lyon1.fr}

  \and

  \IEEEauthorblockN{Laurent Lefèvre}

  \IEEEauthorblockA{LIP Laboratory, ENS Lyon, France\\

  Email: laurent.lefevre@ens-lyon.fr}

}

\maketitle

\begin{abstract}

% TODO RE-READ

Cet article présente la contribution apportée au projet OpenStack, dans le cadre de la réalisation du projet XLcloud.

Il est apparu nécessaire de pouvoir réserver des resources dans le temps, afin d'optimiser la conso énergétique et garantir de bonnes performances dans un contexte HPC. Comme OpenStack ne disposait pas d'un tel mécanisme, nous avons développé un framework de réservation, appelé Climate, qui s'interface avec Nova, l'ordonnanceur d'OpenStack. Climate gère les réservations et l'affectation des hôtes réservés, en tenant compte de leurs performances énergétiques, et fournit un ID de réservation. Cet identifiant de réservation est passé à Nova sous forme de hint, afin qu'il puisse récupèrer auprès de Climate les hôtes réservés. Aucune fonctionnalité n'est enlevé de Nova: il est toujours possible de lancer des instances non réservées, simplement en ne fournissant pas d'id de réservation.

Les propriétés énergétiques des hôtes sont calculées à partir des relevés effectués par les wattmètres, et remontés grâce à Kwapi, pondérés ensuite par la performance en calcul des hôtes.

En fonction du calendrier de réservation et des performances énergétiques des hôtes, il est possible de prendre des décisions d'extinction des machines inutilisées.

La réservation d'hôtes physiques induit parfois de devoir déplacer des machines virtuelles (aggrégation), afin de libérer des hôtes.

\end{abstract}

\section{Introduction}

Avec l'avènement du cloud et la mutualisation des équipements, les utilisateurs sont amenés à partager la même infrastructure. Cette consolidation apporte des avantages certains en terme d'efficacité énergétique et de souplesse d'utilisation.

Cependant, si ce nouveau modèle convient à la plupart des usages, certains usages, tels que le HPC, sont difficilement transposables dans le cloud à l'heure actuelle.

En effet, les applications HPC sont très gourmandes en resources, et sont très sensibles à toute variation de performances entre les noeuds de calcul.

Il faut donc avoir une homonénéité des noeuds en terme de CPU / GPU, mais aussi de réseau (bande passante, latence). Cette homogénéité évite que les noeuds les plus lents ralentissent les plus rapides.

Il faut aussi veiller à ce que l'activité des autres utilisateurs ne perturbe pas les jobs HPC. Pour cela, un utilisateur doit pouvoir réserver des machines, et la portion de réseau utilisée entre elles, afin d'éliminer tout bruit parasite. 

Cette réservation de machine, nécessaire dans un contexte HPC, semble aller à l'encontre de la tendance actuelle à la consolidation. Mais c'est sans compter la spécificité des tâches HPC, qui sont très intensives et accaparent souvent toutes les ressources de calcul des machines. Si la consolidation était possible, elle apporterait non pas des avantages (meilleur taux d'usage et meilleur efficacité énergétique), mais au contraire perturberait la performance des applications HPC, au point de rendre leur exécution dans le cloud impossible.

Or, actuellement, les applications HPC sont exécutés sur des infrastructures privées, souvent surdimensionnées, très onéreuses, et rarement exploitées de façon continue à leur plein potentiel.

OpenStack, solution de cloud open source, connait une forte croissance. Nous proposons donc de lui adjoindre un service de réservation, pour supporter les applications HPC, d'une part, et bénéficier de tous les avantages procurés par un système de réservation, d'autre part.

% TODO nommer les parties (numéros)

Dans cet article, nous verrons dans un premier temps comment pourrait fonctionner un tel service de réservation (spécification des besoins, algorithmes de placements, optimisation de certains critères). Nous passerons en revue les avantages procurés à l'utilisateur et au DCIM, et nous parlerons des modèles de facturation possibles. Dans un second temps, nous décrirons une proposition d'architecture logicielle, qui viendra se greffer sur OpenStack Nova (scheduler). Nous montrerons aussi comment tirer parti de la présence de wattmètres sur les machines, pour choisir les machines les plus efficientes.

\section{Système de réservation}

Pour créer des réservations, l'utilisateur doit pouvoir exprimer ses besoins. Ensuite, un algorithme d'ordonnancement trouve les différentes possibilités en fonction de ces besoins et d'autres critères.

\subsection{Expression des besoins}

% TODO limitation : estimation de la durée, en fonction des hôtes choisis.

% TODO limitation : extension de la durée de réservation et collision avec d'autres réservations... Ou alors accepter l'extension uniquement si ça ne colisionne pas.

L'utilisateur peut vouloir démarrer sa réservation immédiatement, car il possède déjà les données qu'il veut traiter. Il peut aussi anticiper une tâche, et réserver à l'avance pour être sûr d'avoir bien les ressources au moment voulu. Mais s'il est facile de donner une date de début, estimer la durée de sa tâche l'est beaucoup moins. Comme il est très difficile de calculer précisément la durée d'une tâche, le système de réservation devrait permettre de palier à cet inconvénient en permettant à l'utilisateur d'agrandir après coup sa période de réservation, s'il s'apperçoit que sa tâche n'est pas fini lorsque sa réservation va arriver à échéance.

% TODO donner un exemple d'expression

L'utilisateur a parfois une idée très précise des caractéristiques matérielles des hôtes qu'il souhaite réserver, et d'autres fois beaucoup moins.

Pour établir la liste des caractéristiques souhaitées, il doit pouvoir choisir parmi un catalogue de propriétés (modèle de CPU, taille du cache mais aussi capacité réseau, etc). Ensuite, on peut s'inspirer de la grammaire supportée par le Json\_filter de Nova. Avec ce filtre, il est possible d'exprimer ses besoins avec plus ou moins de granularité, et il dispose d'opérateurs logiques. Cependant, dans un contexte HCP, les applications sont sensibles aux disparité de performances entre les noeuds, et il sera nécessaire d'adapter ce Json\_filter. En effet, celui-ci retourne actuellement un unique sous-ensemble à partir d'un ensemble d'hôtes. Or, il serait intéressant de pouvoir obtenir plusieurs sous-ensembles à partir d'un ensemble d'hôtes, chaque sous-ensemble étant homogène sur les propriétés spécifiées. Pour réaliser cette adaptation, nous proposons d'introduire le mot clé "homogeneous".

Ce mot clé pourra être utilisé, par exemple, si le modèle de CPU spécifique n'importe pas, mais que seul le fait que tous les noeuds aient le même CPU est important. L'homogénéité porte en effet surtout sur le CPU, le GPU, et le réseau. En effet, concernant l'espace de stockage, il suffit qu'il soit suffisant. Si un hôte en possède plus, il n'ira généralement pas plus vite.

Ce mot clé donnera au scheduler plus de liberté dans le choix des hôtes. Cependant, il rajoute encore de la difficulté à estimer la durée totale de sa tâche, car les sous-groupes d'hôtes homogènes en performances sélectionnés peuvent être hétérogènes en performances entre eux.

Pour optimiser le placement des réservations, nous demandons à l'utilisateur de préciser des bornes temporelles entre lesquelles placer sa réservation. Il donne donc les paramètres suivants : date du début au plus tôt, date de fin au plus tard, durée de la réservation (à placer entre les deux bornes extrêmes), et les propriétés des hôtes. Pour une réservation immédiate, il suffit fixer les bornes de début et de fin de façon adéquate.

L'utilisateur fournit le nombre d'hôtes nécessaire. Cependant, on pourrait imaginer que le nombre d'hôtes nécessaires puisse varier au cours d'une réservation. L'idéal serait que l'utilisateur puisse faire une réservation en précisant, par tranche horaire, le nombre de noeuds qu'il souhaite voir allumé. Cependant, cela est très difficilement faisable en pratique, car il est difficile de déterminer à l'avance le temps que va prendre chaque étape dans le calcul. Une alternative serait de donner à l'utilisateur la possibilité, au cours d'une réservation, d'aggréger d'autres hôtes à sa réservation, selon ses besoins.

Enfin, l'utilisateur peut préciser sur quelle critère il veut optimiser le placement de sa réservation. Par exemple, démarrer le plus tôt possible, ou utiliser les machines qui consomment le moins d'énergie, ou choisir le créneau horaire où le coût du courant électrique est le plus bas. Il doit pouvoir consulter ces critères dans un catalogue. Cependant, ces critères peuvent entrer en conflit avec l'optimisation effectuée par le DCIM, donc il ne sont pas forcément autorisés.

Pour récapituler, la figure \ref{reservation_parameters_table} présente les paramètres passés par l'utilisateur au système pour créer une réservation.

\begin{table}

\renewcommand{\arraystretch}{1.3}

\caption{Arguments used for creating a reservation}

\label{reservation_parameters_table}

\centering

\begin{tabular}{|l|l|}

\hline

\bfseries Argument & \bfseries Description\\

\hline

start\_time & Not sooner than timestamp \\

end\_time & Not later than timestamp \\

duration & Reservation duration \\

quantity & Hosts quantity \\

host\_properties & Hosts selection criteria \\

scheduler & Scheduler algorithm \\

\hline

\end{tabular}

\end{table}

\subsection{Modèles de réservation}

Il y a deux manières d'enregistrer une réservation : soit c'est au moment de la réservation qu'est choisi un sous-ensemble parmi les hôtes candidats, soit on ne choisit pas les resources au moment de la réservation, mais on garantie seulement que lorsque la réservation deviendra active, on aura suffisament de ressources disponibles. Dans ce dernier cas, il faut considérer chaque réservation comme une règle, et chaque demande d'instanciation ou de réservation, par la suite, comme d'autres règles qui ne peuvent être acceptées que si elles sont compatibles avec toutes les règles précédentes inscrites dans le système.

Le première stratégie permet une meilleure anticipation du coût énergétique pour deux raisons. La première est qu'on connait précisément l'hôte sur lequel la réservation va être lancée, et on peut estimer le coût. La seconde est que si les hôtes les plus efficients sont sélectionnés en priorité, les premiers arrivés ont les hôtes les plus efficients. Donc les instances non réservées, et réservation créées et activées avant la notre ne seront pas placées sur les hôtes les plus efficients, puisqu'il nous sont déjà réservées. Avec cette stratégie, le premier qui réserve a les hôtes les plus efficients.

En revanche, elle est moins robuste si un hôte tombe en panne entre le moment de la réservation et le moment où celle-ci devient active.

La deuxième stratégie est plus robuste à ce niveau là : en cas de panne d'un hôte entre la demande de réservation et le moment où la réservation devient active, il est peu probable que cela impacte la réservation, car il restera probablement des hôtes candidats au moment de la réservation. Cette stratégie, par opposition à la première, favorise les premiers clients qui lancent des instances, concernant l'efficacité énergétique des hôtes.

Il convient aussi de gérer correctement le cas où des instances non-réservées sont instanciées sur un hôte qui a une réservation prévue dans le futur. On peut permettre à de telles instances d'être créées, mais donner la priorité aux réservations : si une réservation doit commencer, les instances non réservées sont soit tuées brutalement, soit mises en pause (moyennant un petit délai), soit migrées sur d'autres hôtes disponibles.

\subsection{Algorithme de réservation}

Le rôle d'un tel algorithme est de trouver quels sont les emplacements libres pour placer une réservation.

Il prend en entrée les paramètres présentés dans la figure \ref{reservation_parameters_table} et retourne en sortie des propositions de placement de réservation.

L'algorithme le plus basique se contente de trouver la première période libre, pendant la durée requise. Pour cela, il trie la liste des hôtes candidats par date de disponibilité au plus tôt. Ensuite, il prend le premier hôte de cette liste, et essai d'aggréger autant d'hôtes que nécessaire sur cette période de temps. S'il n'y en a pas assez, il trouve le second hôte disponible au plus tôt, et recommence le processus.

Des algorithmes bien plus évolués peuvent être mis en place, pour optimiser les réservations en fonction du le coût du courant, ou pour lisser la charge, ou encore limiter les cycles d'extinction/rallumage des machines.

Lorsque plusieurs choix sont possibles, le scheduler à deux possibilités : soit il n'en retourne qu'un, ne donnant aucun choix à l'utilisateur, soit il retourne la liste des propositions et l'utilisateur choisit celle qu'il veut. La première approche nécessite que l'utilisateur décrive en amont les critères de son choix (afin que le scheduler sache laquelle choisir). La deuxième solution peut présenter plus d'intérêt pour le DCIM, qui choisit, selon ses propres critères, le meilleur choix de son point de vue.

De plus, faire choisir l'utilisateur entre plusieurs possibilités revient dévoiler un peu l'usage du datacenter.

Parfois, il serait intéressant de suggérer à l'utilisateur de modifier ses paramètres un petit peu, soit parce qu'aucune réservation n'est possible avec ses critères, soit parcequ'il apparait nettement plus avantageux de modifier ces critères (par exemple une durée un peu moins longue permettrait d'obtenir des machines beaucoup plus efficiente, ce qui peut arranger à la fois l'utilisateur et son fournisseur).

Cependant, ce mécanisme est le moins utilisé sur les plateformes où il serait le plus utile : sur les praformes fermées, où l'usage interne des resources n'est pas transparent, l'utilisateur fait ses requêtes un peu en aveugle. Rien ne lui indique qu'en modifiant un peu sa requête, il obtiendrait satisfaction. Mais si ces plateformes sont fermées, c'est pour une bonne raison, et faire des suggestions serait dévoiler l'état du datacenter.

Cependant, un utilisateur qui voudrait le deviner pourrait faire un grand nombre de requêtes, avec des critères trop sélectifs, et en restreignant petit à petit ses critères, trouver les limites du datacenter.

Il faut donc se prémunir de ce type d'attaque. Une tentative de réservation qui échoue ne peut pas être facturée, donc on ne peut pas jouer sur ce levier. En revanche, on peut fixer des limites aux valeurs extrêmes des paramètres, et limiter le nombre de requêtes par seconde.

\subsection{Annulation de réservation}

Les réservations peuvent être annulées, avant leur fin, afin de ne pas monopoliser des ressources dont l'utilisateur n'a plus besoin, et avant leur commencement, si l'utilisateur change d'avis.

Cependant, une annulation doit entraîner une pénalité pour l'utilisateur, car celui-ci pourrait faire des réservations multiples suivies d'annulations pour tenter de deviner l'infrastructure du datacenter. Et d'autre part, une annulation avant la fin d'une réservation dénote une mauvaise estimation de la durée de la réservation.

Cette pénalité se traduit par un remboursement à moins de 100\%, de la durée de réservation qui n'a pas encore été consommée.

Avant le début de réservation, plus celle-ci est annulée tôt, plus le pourcentage de remboursement est élevé. Cependant, si elle est annulée immédiatement, la réservation n'est pas remboursée à hauteur de 100\%. Après le début de la réservation, plus l'utilisateur l'annule tard (proche de sa date de fin), plus le pourcentage de remboursement tend vers 100\%.

\subsection{Facturation}

Grâce au service de réservation, un client est seul sur l'hôte réservé, ce qui permet une facturation à l'usage précise et incontestable.

En effet, sur des environnements sans réservation, il est difficile de répartir les coûts entre plusieurs utilisateurs, s'ils se partagent les mêmes machines. Il existe bien des modèles pour estimer la consommation par VM, mais il est difficile de prouver à un utilisateur sa consommation, et se pose aussi le problème de la répartition du coût statique de l'hôte: en effet, un serveur qui ne fait rien consomme quand même, donc plus il y a d'utilisateurs qui se partagent cette machine, moins ce coût est élevé par utilisateur. Une facturation à l'usage incite les clients à optimiser leurs programmes, et permet une facturation équitable des clients.

La facturation prend en compte une part statique et une part dynamique.

\subsubsection{Part statique}

\paragraph{En fonction de la performance des machines}

Les machines les plus performances doivent coûter plus cher, car elles sont plus récentes, plus onéreuses, et sont très souvent utilisées par des utilisateurs pressés même si on en augmente le coût. Ainsi, pour un même ratio flop/w, la machine la plus rapide devra coûter plus cher.

\paragraph{En fonction de la charge}

Grâce à un service de réservation le DCIM peut faire des prévisions d'usage du cloud, et ainsi proposer des tarifs plus avantageux durant les heures creuses. Au contraire, durant les pics de charge, le tarif pourra être plus élevé. Cela permet de tenir compte du coût de l'énergie qui peut être variable, afin d'en répercuter le coût sur les utilisateurs. De plus, lisser la charge et éviter les pics peut permettre un meilleur taux d'usage global du datacenter, et faciliter son implantation dans des zones où la puissance max qu'il est possible de tirer est plafonnée.

Cependant, proposer des tarifs variable en fonction du temps dévoile quelle est l'activité du datacenter. Selon le degré de transparence du fournisseur, celui pourra choisir de proposer une variation de tarif à plus ou moins fine granularité, afin de préserver un certain niveau de confidentialité. Par exemple, des tarifs variants heure par heure dévoilent beaucoup de choses sur l'activité du datacenter, tandis que s'ils varient par chaque mois, cela masque de l'information. Cependant, même avec une variable à grosse granularité, il sera possible de dégager des courbes de tendances, qui peuvent être porteuse de beaucoup d'informations. De plus, une grosse granularité aura tendance à favoriser les clients plus aggressifs et pénaliser ceux dont les réservations sont placées au endroits les meilleurs. Faut-il mieux risquer de perdre certains clients aggressifs, ou perdre des clients souples ?

\subsubsection{Part dynamique}

Il s'agit du coût du courant électrique réellement utilisé (en prenant en compte la consommation idle des machines).

\section{Architecture}

Dans cette section, nous décrivons notre architecture logicielle telle qu'elle sera implémentée dans un premier temps.

Nous utiliserons la stratégie de réservation qui consiste à choisir les hôtes au moment de la réservation.

\begin{figure*}[!t]

\centerline {\includegraphics[width=14cm]{figures/architecture.eps}}

\caption{Global architecture}

\label{fig_architecture}

\end{figure*}

\subsection{Climate}

Notre architecture vise à apporter des fonctionnaliés supplémentaires d'ordonnancement, sans pour autant être intrusif au niveau Nova.

Nova se compose d'une interface API, et d'un ensemble de filtres et pondérateurs.

Voici quel est le workflow actuellement utilisé dans OpenStack: lorsqu'un utilisateur souhaite instancier une VM, il passe en paramètres un certains nombre de critères (flavor, etc), et l'ordonnanceur Nova commence par filtrer les hôtes pour garder ceux qui correpondant aux besoins de l'utilisateur. Ensuite, Nova pondère les hôtes restants grâce à des pondérateurs. Il existe un certain nombre de filtres déjà programmés dans Nova, et un pondérateur, qui prend en compte la RAM disponible.

Cette infrastructure nécessiterait, comme nous l'avons dit, l'ajout d'un filtre pour garder les hôtes homogènes. Mais d'autres problèmes se posent qui nous conduisent à externaliser la filtration des hôtes à l'extérieur de Nova : en effet, pour placer une réservation de façon optimale, il est nécessaire d'avoir une vue sur le calendrier de réservation. Intégrer ceci dans Nova, à travers les filtres ou les pondérateurs personnalisés, ne semble pas être le meilleur design.

\subsubsection{API}

L'API offre les fonctionnalités de gestion des réservations.

Pour créer les réservations, les utilisateurs utilisent les paramètres suivants : host\_properties (propriétés des hôtes), start\_time (date de début au plus tôt), end\_time (date de début au plus tard), duration (durée de la réservation), quantity (nombre d'hôtes à réserver).

Si l'utilisateur ne précise par les paramètres start\_time et end\_time, la réservation est de type immédiate (elle commence maintenant et dure la durée précisée). Sinon, il est possible de planifier une réservation dans le futur. La réservation dans le futur peut permettre aux utilisateurs de s'assurer de bien avoir les resources au moment voulu. On peut aussi imaginer des modèles de facturation différents si l'utilisateur anticipe ses réservations.

Dans un premier temps, le paramètre "scheduler" n'est pas disponible à l'utilisateur.

Climate dispose d'un frontend REST API pour la gestion des réservations, qui exploite deux backends (Inventory et Scheduler).

L'API effectue deux étapes pour traiter la requête de création de réservation. Premièrement elle contacte Climate Inventory pour trouver les hôtes qui correspondent aux prérequis précisés dans host\_properties, et qui sont disponibles.

Secondement, les hôtes filtrés sont passés, ainsi que les paramètres de l'utilisateur, à Climate Scheduler, et celui-ci trouve une période libre où mettre la réservation.

L'API de Climate n'est pas seulement utilisée par les utilisateurs.

Nova l'utilise aussi, pour trouver les hôtes non réservés ou attachés à une réservation, ainsi que tous les modules qui auraient besoin de consulter le calendrier des réservations.

Cette API est sécurisée par l'emploi des tokens Keystone. Selon le rôle correspondant à ce token, elle permet ou non de retrouver l'ID des hôtes physiques attachés à un réservation. En effet, il s'agit d'une information plus ou moins confidentielle, cachée aux utilisateurs simples qui n'ont pas un rôle d'administrateur.

\begin{table}

\renewcommand{\arraystretch}{1.3}

\caption{Climate API}

\label{climate_api_table}

\centering

\begin{tabular}{|l|l|l|}

\hline

\bfseries Method & \bfseries URL & \bfseries Description\\

\hline

GET & /properties/ & Lists the properties\\

POST & /reservations/ & Creates a réservation\\

GET & /reservations/ & Lists the réservations\\

GET & /reservations/<réservation-id> & Describes a réservation\\

DELETE & /reservations/<réservation-id> & Cancels a réservation\\

\hline

\end{tabular}

\end{table}

\subsubsection{Inventory}

Il s'agit d'un service RPC, interrogé par Climate API pour retrouver les hôtes candidats à une demande de réservation.

Les hôtes candidats sont ceux qui matchent les propriétés requises par l'utilisateur, et ne sont pas utilisés (leur champ running\_vm = 0 dans la base Nova). L'API de Nova est interrogée grâce au NovaClient, et le filtrage utilise la syntaxte du json\_filter de Nova.

L'inventaire prend en paramètre les host\_properties. Mais l'utilisateur doit être capable d'élaborer un tel filtre. Pour cela, il utilise la méthode de l'API /properties/, qui fournit un catalogue des propriétés que l'on peut trier. Cette méthode liste les propriétés présentes dans les détails de hôte enregistrés dans la base Nova, mais le DCIM peut en masquer certaines, et en ajouter d'autres.

\subsubsection{Power}

Climate Power permet de gérer les modes de veille des machines. Comme Climate dispose d'un calendrier de réservation dans le temps, il est facile de s'en servir pour savoir quand mettre en veille et allumer les machines. Pour prendre une décision, il faut tenir compte des prochaines réservation qui vont devenir active, et de la probabilité qu'une réservation non réservée soit ordonnancée sur une machine donnée. Lorsque qu'une réservation devient active, soit l'utilisateur a immédiatement besoin de toute ses ressources (dans ce cas là ce module devra anticiper les réservations qui vont devenir active et allumer les machines en avance), soit il veut simplement avoir la garantie de disposer d'un certain nombre de machines, mais n'est pas très regardant sur le délai de mise en route. Dans ce dernier cas, laisser ses machines en veille un peu plus longtemps lui fera économiser la consommation idle. Ou pourrait par exemple donner la possibilité à l'utilisateur de préciser le nombre de machine qu'il souhaite utiliser immédiatement.

L'utilisateur doit avoir accès à l'API de Climate Power pour gérer lui même la consommation de ses machines en fonction du temps, s'il n'a pas besoin de la même quantité de machine dans le temps. Nova aussi utilise cette API, pour allumer un hôte lorsqu'une instance non-réservée doit y être lancée.

Climate doit choisir quel mode de veille utiliser. Plus la veille est profonde, puis cela met du temps à rallumer la machine et plus cela est coûteux en terme d'énergie.

Il faut aussi éviter d'éteindre et rallumer trop souvent les machines, pour une question d'usure du matériel (on peut immaginer que plus la machine a été rallumée/éteinte, moins elle a de chance de changer d'état. Cependant, cela favorise les vieilles machines, qui sont pourtant les moins efficaces.

\subsection{Nova}

Nova est le module de lancement d'instances d'OpenStack. Par défaut, lorsqu'un instance doit être chargée, les hôtes passent dans des filtres qui ne laissent passer que les hôtes éligibles. Ensuite, les hôtes restants sont pondérés, et ceux de poids les plus faibles sont élus. Le scheduler permet de passer des scheduler\_hint.

Nova facilite l'intégration de filtre et pondérateurs tiers, en permettant à l'utilisateur de préciser dans le fichier de configuration de Nova le nom du module Python correspondant à l'élément tier à charger. Cette classe hérite d'une classe Nova, et implémente les méthodes nécessaires.

L'utilisateur peut passer des hints en arguments, et les filtres récupérerent leur valeur.

Ainsi, Climate exploite l'architecture extensible permise par Nova, en fournissant filtres et pondérateurs.

\subsubsection{Filtering}

Le filtre Nova accepte un scheduler hint, nommé réservation\_id, qui est l'ID de la réservation retourné par Climate au moment de la réservation.

Si l'utilisateur fournit une réservation ID, le filtre contacte Climate API, en fournissant un token admin, et retrouve ainsi la liste des hôtes associés à la réservation.

Si l'utilisateur ne fournit pas de réservation ID, Nova contacte Climate pour établir la liste de tous les noeuds réservés à cet instant donné. Seuls les hôtes qui ne sont pas dans cette liste sont éligibles.

\subsubsection{Weighing}

Nous créerons deux Nova pondérateurs.

Le premier pondérera les machines en fonction du temps libre jusqu'à la prochaine réservation : dans le cas d'une instance non réservée, il faudra scheduler cette instance sur la machine qui est libre pendant le plus longtemps, afin de diminuer la probabilité de devoir migrer la VM, si l'utilisateur n'a toujours par libéré son instance et que l'hôte sur laquelle est tourne va bientôt être réservé par une réservation qui devient active. Dans le cas d'une instance réservée, cette étape est sautée.

Le second pondérera les machines en fonction de leur efficacité énergétique. Ce filtre contactera Kwranking, en passant la liste des hôtes en paramètre. Il trie ensuite le résultat pour ne garder que les hôtes les plus efficients.

Il faudra veiller à la pondération, afin que le premier filtre ait une "haute priorité".

\subsection{Kwapi}

Kwapi is our framework, designed for acquiring energy consumption metrics. It allows, among other, to upload metrics from the wattmeters to Ceilometer.

Its architecture is based on a layer of drivers, responsible for the acquisition metrics, and a layer of plugins that collect these metrics. The communication between these two layers goes through a bus.

Drivers and plugins are easily extensible to support other types of wattmeters, and provide other services.

\subsubsection{Drivers layer}

The drivers are threads started by a manager, which instantiate them with a set of parameters loaded from a configuration file (unified with the OpenStack configuration file format, similar to INI). These parameters are used to query the meters (IP address, port, etc.) and indicate the sensor IDs in the issued metrics. The metrics are Python dictionary with a set of fields. Optional fields can be added, such as voltage, amperage, etc.. The metrics are signed.

The manager periodically checks if all threads are active, and restart them if necessary (incidents may occur, for example if a meter is disconnected or becomes inaccessible). The drivers can manage incidents themselves, but if they finish their execution, it does not matter because they will be automatically restarted by the manager. It is important to avoid losing measurements because the information reported is watts and not kWh: if a value in watts is lost, we lose information.

\subsubsection{Plugins layer}

The plugins retrieve and process the metrics sent by the drivers on the bus. They expose them to other services (Ceilometer) or user (visualization). They can subscribe to all sensors, or just some of them, through a system of prefixes. After verifying the message signature, they extract the fields, and process the received data. Kwapi has a plugin API for Ceilometer, which computes the number of kWh of each probe, appends a timestamp, and stores the last value in watts. These data are not stored in a database, as Ceilometer already has one. If a probe has not issued metrics for a long time, the corresponding data are removed. This plugin has a REST API that allows to retrieve the name of the probes, and W, kWh and timestamp.

\subsection{Kwranking}

Pour améliorer l'efficacité énergétique, il faut que les machines les plus efficientes soient utilisées en priorité (en particulier pour les tâches qui demandent beaucoup de puissance).

L'efficacité énergétique se définit en flops/w, donc il faut pondérer les valeurs de consommation récupérées depuis les wattmètres par un indice de performance.

Cet indice peut être obtenu à l'aide d'un benchmark, mais cela oblige à exécuter ce benchmark sur les machines au après leurs installation dans le datacenter. L'autre solution, plus simple à mettre en place, est d'estimer la performance à partir des propriétés CPU (ou GPU) de l'hôte. Cela fait sens dans la mesure où le CPU et le GPU comptent parmi les composants les plus énergivores et dont la puissance demandée est fonction de la charge soumise.

Pour élaborer cet indice, on prend en compte la famille du processeur, le nombre de puces, de coeurs et de threads, ainsi que la mémoire cache et la fréquence.

La famille du processeur compte beaucoup, car elle conditionne le jeu d'instruction disponible. C'est d'ailleurs pour cette raison qu'une mesure en Bogomips n'a pas de sens, car cet indice tient compte uniquement du nombre de fois où le processeur est capable de ne rien faire par seconde. Cela ne prend pas en compte le jeu d'instruction plus ou moins optimisé.

% TODO flop/w, pour le min, l'avg ou le max ?

Dans le cadre de notre infrastructure énergétique, nous mémorisons, pour chaque hôte, sa consommation min, avg, et max, et l'indice en flop/w.

Kwranking est capable d'enrichir une liste hôte avec leurs propriétés énergétique (sans faire de tri toutefois).

Cette fonctionnalité est utilisée lors du choix des hôtes, à deux reprises.

La première fois au moment de la réservation : par exemple, si l'utilisateur veut des processeurs homogènes, plusieurs familles de processeurs seront candidates, et celles-ci seront pondérées par Kwranking. La seconde fois, au moment de l'instanciation de VMs : d'une part, certaines machines peuvent être plus chaudes que d'autres, et la vitesse des ventilateurs impactent sur la consommation, et d'autre part, des hôtes strictement identiques d'un point de vue matériel peuvent présenter des différences de consommation allant jusqu'à 20\% (cela est du aux aléas de la fabrication des puces). Il s'agit donc de choisir, au moment d'une instantiation de VM, quel est l'hôte le moins consommateur parmis les hôtes réservés.

De même, parmi les hôtes réservés, on aura tentance à mettre en veile ceux qui consomment le plus.

L'utilisation de ce module consiste à lui passer une liste d'hôtes en paramètre, qu'il retourne enrichie, pour chaque hôte, de sa la métrique en flop/w, la conso min, avg, max.

\subsection{Kwassign}

La facturation devrait tenir compte de l'usage qui est fait des ressources. Cela permet d'inciter les clients à mieux optimiser leur programmes et permet à ceux dont les programmes sont légers d'avoir des tarifs plus abordables.

Ce modèle de facturation nécessite deux choses : la première est d'avoir des équipements de mesures de la consommation énergétique, et la seconde de pouvoir assigner ces mesures à un utilisateur particulier. Les environnements mono-tenancy se prêtent bien à cette opération, car il n'y a pas besoin de recourir à des estimations de la consommation des VMs, qui pourraient être remises en question.

Kwapi, le framework de remontée énergétique, ne connait pas quel utilisateur était assigné à telle machine à un moment donné.

Ces valeurs sont stockées dans Ceilometer collector, et il serait souhaitable de les assigner aux clients avant leur stockage, afin qu'ils puissent librement interroger l'API de Ceilometer et retrouver leur consommation énergétique. De plus, cette assignation a besoin de se fait qu'une seule fois.

Nous avons donc créé un module logiciel qui se branche sur le bus de Ceilometer, et modifie à la volée les métriques remontée, en leur assignant un propriétaire. Pour cela, il interroge le calendrier de réservation de Climate.

En revanche se trouve dans Climate le calendrier de réservation.

Dans le cas de réservations non réservés, et donc en environnement potentiellement multi-tenancy, on ne réalise aucune assignation, et on ne rend pas non plus accessible la consommation des machines concernées, car cela dévoilerait l'activité des autres utilisateurs.

Kwassign écoute donc le bus de Ceilometer, modifie et republie les métriques.

Ce design un peu intrusif pourrait cependant évoluer. Il est impossible d'annuler les métriques publiées par le pollster, ce qui fait que les métriques sont stockées deux fois dans Ceilometer collector. Une fois assignées, et une fois pas assignées. Il faudrait donc mieux que ce soit le pollster qui gère l'assignation.

\section{Limitations}

Nous pouvons identifier deux types de limitations : celles inhérentes au système de réservation, et celles portant sur des éléments techniques susceptibles d'évoluer.

Il serait souhaitable de donner des conseils de placement à l'utilisateur, pour diminuer sa facture (en économisant de l'énergie), ou honorer une requête trop contraignante. Cependant, il ne faut pas non trop d'éléments sur le datacenter.

S'il n'y a plus assez de machines libres pour honorer une demande de réservation, les instances non réservées pourraient être migrées et aggrégées afin de libérer de la place. Pour cela, il faut regrouper ces instances, en fonction du type d'hôte requis.

% \section{Scénarios envisagés}

% Un service de réservation permettrait de réaliser les scénarios suivants.

% \subsection{Provider spécialisé HPC}

% On peut voir le cloud comme un ensemble de resources, appartenant à un, ou plusieurs propriétaires s'il s'agit de plusieurs clouds mutualisés grâce à un broker.

% Parmi cet ensemble de resources, il existe des sous-ensembles qui sont suffisament homogènes sur certains critères pour pouvoir intéresser des clients avec des besoins spécifiques. Ces clients peuvent être des particuliers, mais aussi des entreprises spécialisées dans la vente de ressources de cloud. Par exemple, une entreprise spécialisée dans la fourniture d'infrastructure HPC pourrait réserver tous les noeuds qui se prêtent à cette activité.

\section{Conclusion}

Nous avons vu que dans un contexte HPC, pouvoir avoir la garantie d'être seul sur sa machine était indispensable. Pour cela, il y a besoin d'avoir un système de réservation de ressources. Ce calendrier de réservation des ressources impliqué dans un tel système peut aisément être exploité pour bénéficier d'autres avantages.

D'un point de vue utilisateur, la réservation permet de garantir l'accès au ressources dans le futur. Sans réservation, il y aurait une concurrence accrue entre les utilisateurs, et il ne serait pas possible aux utilisateurs prévoyant d'avoir plus de chances d'accéder aux ressources en anticipant leur réservation.

Pour le DCIM, il est possible prévoir la charge du datacenter, et de proposer des tarifs qui varient en fonction de cette charge, pour inciter les utilisateurs à réserver durant les périodes creuses. Cela permet donc d'une part un lissage du trafic, et d'autre part on peut imaginer la possiblité pour le DCIM de plafonner la consommation énergétique : en connaissant les réservations à l'avance (en tout cas dans le cas du modèle où les hôtes sont choisis au moment de la réservation) il est possible de savoir s'il peut accepter des nouvelles réservation durant une période donnée, sans dépasser la consommation instantannée maximale qu'il se sera fixée.

D'autre part, le contexte HPC nécessitait d'obtenir des noeuds à performances homogène. Devant la variété des besoins utilisateurs, il est apparu nécessaire de lui donner la possibilité de décrire les caractéristiques de ses hôtes avec une fine granularité. Et selon les hôtes candidats et leurs périodes de disponibilité, le système peut s'appuyer sur des stratégies internes afin d'optimiser certains critères (efficacité énergétique, charge du datacenter, coût du courant électrique, etc). Ces stratégies étant choisies soit par le DCIM, soit par l'utilisateur.

Un tel système de réservation de ressources s'applique ici à la réservations d'hôtes entier, mais il pourrait être généralisé à bien d'autres types de ressources (espace de stockage, réseau, etc).

\section*{Acknowledgment}

Not yet available.

% This research is supported by the French FSN (Fonds national pour la Société Numérique) XLcloud project. Some experiments presented in this paper were carri

% ed out using the Grid'5000 experimental testbed, being developed under the INRIA ALADDIN development action with support from CNRS, RENATER and several Univ

% ersities as well as other funding bodies (see https://www.grid5000.fr). Authors wish to thank Julien Danjou for his help during the integration of Kwapi wit

% h Openstack and Ceilometer.

\section*{References}

Not yet available.

\end{document}