commit cb3752a0826d97ada11cac80161175b91a33defb
Author: François Rossigneux <francois.rossigneux@inria.fr>
Date:   Thu Jul 18 20:01:01 2013 +0200

    Climate paper update.

diff --git a/papers/2013/Climate-Paper/paper.tex b/papers/2013/Climate-Paper/paper.tex
index 6d1017a..8654776 100644
--- a/papers/2013/Climate-Paper/paper.tex
+++ b/papers/2013/Climate-Paper/paper.tex
@@ -45,7 +45,7 @@ Avec l'avènement du cloud et la mutualisation des équipements, les utilisateur
 Cependant, si ce nouveau modèle convient à la plupart des usages, certains d'entre eux, tels que le HPC, sont difficilement transposables dans le cloud à l'heure actuelle.
 En effet, les applications HPC sont très gourmandes en ressources, et très sensibles à toute variation de performances entre les noeuds de calcul.
 Il faut donc avoir une homogé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 toute perturbation. 
+Il faut aussi veiller à ce que l'activité des autres utilisateurs ne perturbe pas les tâches HPC. Pour cela, un utilisateur doit pouvoir réserver des machines, et la portion de réseau utilisée entre elles, afin d'éliminer toute perturbation. 
 Cette réservation de machine physique, 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.
 
@@ -57,126 +57,84 @@ Dans cet article, nous verrons dans un premier temps comment pourrait fonctionne
 \section{État de l'art}
 On s'intéresse ici à la manière de réserver des ressources de calcul. Ces ressources peuvent être virtuelles (des instances avec des caractéristiques données) ou physiques (un noeud de calcul).
 
-Dans cet état de l'art, nous étudierons Amazon EC2, une plateforme célèbre et qui supporte plusieurs modes de réservation d'instances. En la comparant avec d'autres plateformes, et notamment Windows Azure, nous constatons que le modèle de réservation d'Amazon est le plus riche.
-Nous prendrons donc celui-ci pour référence par la suite.
+\subsection{Amazon EC2}
+La plateforme Amazon EC2 propose un système de location de ressources qui convient à beaucoup de cas d'utilisation différents.
+En la comparant avec d'autres plateformes, et notamment Windows Azure, nous constatons que le modèle de réservation d'Amazon est le plus riche.
 
-Aucune plateforme commerciale ne supporte la réservation de noeuds physiques. En effet, cela conduirait à dévoiler les caractéristiques de ces noeuds, ce que ne souhaitent pas les fournisseurs. C'est pourquoi les plateformes commerciales n'acceptent pas ce type de réservation.
-En revanche, Grid'5000, une plateforme d'expérimentation scientifique, permet de réserver des noeuds physiques. L'utilisateur est donc dans un environnement single-tenant.
-
-Concernant la manière de préciser les caractéristiques matérielles des hôtes requises, toutes les plateformes, à l'exception de Grid'5000, demandent à l'utilisateur de sélectionner les instances parmi une liste d'instances types (petit, moyen, grand). On parle ici des caractéristiques d'instances, et non pas des caractéristiques des hôtes qui hébergent ces instances.
-Le fonctionnement de Grid'5000 est différent : l'utilisateur réserve non pas des instances, mais des hôtes physiques. Comme l'infrastructure est publique, il n'est pas gênant de dévoiler cette infrastructure et l'utilisateur est autorisé à préciser les caractéristiques matérielles que doivent posséder les hôtes. Ces caractéristiques sont renseignées par les administrateurs de la plateforme, et l'utilisateur peut en obtenir une liste.
-
-Voyons maintenant en détail les instances supportées par Amazon EC2.
 Amazon fournit quatre types d'instances: à la demande, réservées, ponctuelles, et dédiées (au sein d'un Virtual Private Cloud).
 
 Les instances à la demande ont un tarif horaire plus élevé que les instances réservées, mais ne nécessitent pas de payement préalable. L'accès au ressources n'est pas garantie en cas de pic de charge. Ce type d'instance convient aux applications à court terme, qui demandent une quantité de resources variable, et qui ne peuvent pas être interrompues.
-Windows Azure et OVH supportent ces types d'instances.
+Ce type d'instances est généralement proposé par les fournisseurs de clouds (Windows Azure, etc).
 
 Les instances réservées demandent à faire un payement préalable (réservation sur un à trois ans). Le taux horaire est ensuite bien plus avantageux.
-L'accès aux resources est garanti. Ces instances sont parfaites pour les applications stables et prévisibles, ou qui nécessitent une quantité de ressource donnée (récupération après désastre).
-Windows Azure et OVH supportent ces types d'instances.
+L'accès aux resources est garanti. Ces instances sont parfaites pour les applications stables et prévisibles, ou qui nécessitent une quantité de ressource donnée (récupération après désastre). Les instances réservés peuvent être revendues sur la place de marché Amazon, au prix choisit par le vendeur.
+Ce type d'instances est aussi très souvent proposé par les fournisseurs de clouds (Windows Azure, etc).
 
 Les instances ponctuelles permettent à l'utilisateur de préciser le coût maximum horaire qu'il est prêt à payer. Il n'y a pas de payement préalable, et les instances sont tuées si le coût horaire dépasse celui précisé par l'utilisateur (en fonction de l'offre et de la demande).
 Ce type d'instance est adapté aux applications avec des dates de début et de fin flexibles, qui ne sont faisable qu'à très bas coût (ces instances sont moins chères que les instances à la demande), ou qui sont très urgentes (ces instances sont utilisées pour rajouter à la volée de la capacité additionnelle). La facturation se faisant à l'heure, la dernière heure "partielle" n'est pas facturée (à moins que l'utilisateur termine volontairement son instance).
-Seul Amazon EC2 supporte cette fonctionnalité. Le mode best effort de Grid'5000 s'en rapproche (mais il n'y a pas de facturation) : une tâche best effort est tuée si quelqu'un a besoin de la machine sur laquelle elle tourne.
+À notre connaissance, seul Amazon EC2 supporte cette fonctionnalité.
 
 Enfin, les instances dédiées sont disponibles dans l'offre Virtual Private Cloud (VPC). Le VPC permet de constuire un pont sécurisé entre l'infrastructure locale (d'une entreprise) et l'insfrastructure Amazon, en passant par un VPN. Les instances à l'intérieur de ce VPC sont isolées des autres instances (au niveau réseau). Par défaut (sans instances dédiées), les instances appartenant à un VPC peuvent être exécutées sur des machines partagées entre plusieurs clients. Pour être certain d'être dans un environnement single-tenant, il faut utiliser des instances dédiées.
 On remarquera que plusieurs instances dédiées appartenant au même client ne sont pas forcément lancées sur la même machine, afin de diminuer l'impact en cas de panne matérielle.
-Ces instances dédiées fournissent un environnement single-tenant, tout comme Grid'5000, où l'utilisateur réserve des noeuds physiques entiers.
-
-OVH permet de réserver des machines dans son offre Dedicated Clouds. Cette offre s'appuie sur vCloud et vSphere de VMware.
-L'utilisateur obtient des ressources dédiées (même le réseau), et il est possible d'ajouter et de supprimer des noeuds à la demande.
-Il existe une dizaine de configurations proposées. La facturation est à l'heure.
-
-Haizea est un système de reservation et de scheduling proposé à l'origine pour OpenNebula. Il supporte différents types de réservations (immédiates, futures et best effort). Il prend en compte les ressources et le temps nécessaire pour préparer la réservation (transfert des images), et celles occupées par les VMs. Ainsi, les réservations peuvent commencer précisément à l'heure requise, et l'utilisateur obtient exactement la quantité de mémoire libre qu'il a demandé.
-
-% citrix
-% ovh
-% OpenNebula: Haizea
-
-% \paragraph{On-demand instances} let you pay for compute capacity by the hour with no long-term commitments or upfront payments. You can increase or decrease your compute capacity depending on the demands of your application and only pay the specified hourly rate for the instances you use. Amazon EC2 always strives to have enough On-Demand capacity available to meet your needs, but during periods of very high demand, it is possible that you might not be able to launch specific On-Demand instance types in specific Availability Zones for short periods of time.
-% 
-% On-Demand Instances are recommended for:
-% \begin{IEEEitemize}
-%   \item Users that want the low cost and flexibility of Amazon EC2 without any up-front payment or long-term commitment
-%   \item Applications with short term, spiky, or unpredictable workloads that cannot be interrupted
-%   \item Applications being developed or tested on Amazon EC2 for the first time
-% \end{IEEEitemize}
-% 
-% \paragraph{Reserved instances} let you make a low, one-time, upfront payment for an instance, reserve it for a one or three year term, and pay a significantly lower hourly rate for that instance. You are assured that your Reserved Instance will always be available for the operating system (e.g. Linux/UNIX or Windows) and Availability Zone in which you purchased it. For applications that have steady state needs, Reserved Instances can provide savings of up to 71\% compared to using On-Demand Instances. Functionally, Reserved Instances and On-Demand Instances perform identically. See "How to Purchase Reserved Instances" for more information.
-% 
-% Reserved Instances are recommended for:
-% \begin{IEEEitemize}
-%   \item Applications with steady state or predictable usage
-%   \item Applications that require reserved capacity, including disaster recovery
-%   \item Users able to make upfront payments to reduce their total computing costs even further
-% \end{IEEEitemize}
-% 
-% \paragraph{Spot instances} provide the ability for customers to purchase compute capacity with no upfront commitment and at hourly rates usually lower than the On-Demand rate. Spot Instances allow you to specify the maximum hourly price that you are willing to pay to run a particular instance type. Amazon EC2 sets a Spot Price for each instance type in each Availability Zone, which is the price all customers will pay to run a Spot Instance for that given period. The Spot Price fluctuates based on supply and demand for instances, but customers will never pay more than the maximum price they have specified. If the Spot Price moves higher than a customer’s maximum price, the customer’s instance will be shut down by Amazon EC2. Other than those differences, Spot Instances perform exactly the same as On-Demand or Reserved Instances. See here for more details on Spot Instances.
-% 
-% Spot Instances are recommended for:
-% \begin{IEEEitemize}
-%   \item Applications that have flexible start and end times
-%   \item Applications that are only feasible at very low compute prices
-%   \item Users with urgent computing needs for large amounts of additional capacity
-% \end{IEEEitemize}
-% 
-% \paragraph{Dedicated}
-% 
-% Dedicated instances is available in Virtual Private Cloud (VPC) offerings. Dedicated Instances run on single-tenant hardware. They are physically isolated at the host hardware level from your other instances and instances that belong to other AWS accounts. 
-% 
-% Reserved instance and dedicated hardware can be combined. Which means that an instance that has been reserved can be launched on single-tenant hardware . This use case is close from the concept of Capacity Leasing Service. A notable difference between the Capacity Leasing Service and AWS is two-fold:
-% 
-% \begin{IEEEitemize}
-%   \item With AWS, dedicated instance can be launched only into a virtual private cloud (VPC) whereas with the Capacity Leasing Service dedicated hardware is reserved at the project level. If a VPC is created with the instance-tenancy option set to 'dedicated' then all instances are launched as dedicated tenancy instance regardless of the tenancy assigned at launch.
-%   \item With AWS dedicated instances are virtual. The Capacity Leasing Service allows to reserve physical machines that could/should be usable to instantiate virtual machines but also physical machines through the bare-metal provisioning extensions of OpenStack Nova.
-% \end{IEEEitemize}
-% 
-% The model offered by AWS seems to be quite different than the model proposed by the Capacity Leasing Service in that the combine effect of reserved instance and dedicated tenancy doesn't seem to effectively guarantee the reservation of physical resources.
+Les instances dédiées se rapprochent de la réservation de ressources physiques, à la différence que les caractéristiques de l'hôte physique ne sont pas choisies par l'utilisateur.
+
+\subsection{OVH}
+OVH propose deux offres Dedicated Cloud, qui reposent sur VMware.
+L'offre vSphere as a service propose un cloud dédié, avec une visibilité sur le matériel, tandis que l'offre vCloud as a service fait abstraction du matériel. Une dizaine de configurations serveurs sont proposées, que l'utilisateur peut choisir avec l'offre vSphere as a service.
+Dans tous les cas, il peut rajouter des ressources ou en enlever selon ses besoins. La facturation est à l'heure.
+
+\subsection{Grid'5000}
+Grid'5000 est une plateforme d'expérimentation scientifique, qui diffère des solutions commerciales sur de nombreux points.
+Son infrastructure est publique et l'utilisation gratuite. C'est la seule plateforme parmi celles étudiées ici qui permet de réserver des ressources en avance, et en précisant les caractéristiques des hôtes souhaitées. Toutes les autres plateformes (à l'exception des OVH Dedicated Clouds) font choisir l'utilisateur parmi une liste de "flavors".
+En effet, contrairement aux plateformes commerciales qui sont réticentes à dévoiler leur infrastructure physique, Grid'5000 fournit beaucoup de détails sur les hôtes physiques, ce qui permet à l'utilisateur de les choisir en fonction de leurs propriétés. Les hôtes physiques réservés sont affectés à l'utilisateur au moment de la réservation.
+L'utilisateur se retrouve dans un environnement single-tenant (comme sur un instance dédiée Amazon), à la différence qu'il a pu choisir le matériel sous-jacent.
+Grid'5000 dispose aussi d'un mode best effort, qui ressemble aux instances ponctuelles d'Amazon. La différence est qu'avec Amazon, une instance ponctuelle est interrompue si le prix devient trop élevé, tandis que dans Grid'5000, comme il n'y a pas de facturation, l'instance est tuée si un utilisateur a réservé la machine sur laquelle l'instance best effort est exécutée.
+
+\subsection{Bilan}
+À l'heure actuelle, seul Grid'5000 permet de réserver des ressources à l'avance, avec des hôtes attribués au moment de la réservation.
+
+Il n'est pas possible de réserver des ressources en avance avec OpenStack.
+À notre connaissance, seul OpenNebula propose ce type de service, s'il est couplé avec Haizea.
+Haizea est un système de reservation et d'ordonnancement qui supporte différents types de réservations (immédiates, futures et best effort). Il prend en compte les ressources et le temps nécessaire pour préparer la réservation (transfert des images), et celles occupées par les VMs. Ainsi, les réservations peuvent commencer précisément à l'heure requise, et l'utilisateur obtient exactement la quantité de mémoire disponible qu'il a demandé.
+Il peut être couplé à OpenNebula, ou fonctionner en mode simulation.
+Haizea est écrit en Python et est sous licence Apache 2, comme OpenStack. Haizea a été créé en décembre 2009.
+
+OpenStack n'offre pas un mécanisme simple et élégant, permettant à l'utilisateur de découvrir les propriétés des hôtes disponibles, pour ensuite constuire un filtre pour l'ordonnanceur. Certes, il est possible de lister les hôtes pour obtenir des détails (notamment les CPU infos), mais il serait souhaitable que toutes ces informations soient stockées dans une Configuration Management DataBase (CBDM), dans laquelle l'administrateur pourrait ajouter des informations (par exemple la latence entre chaque noeud), et choisir si elles peuvent êtres exposées à l'utilisateur. Ce dernier pourrait ensuite lister le propriétés disponibles (en parcourant la hiérarchie), et voir les valeurs disponibles pour chacune d'entre elles. Par exemple, sous le noeud "cpu" se trouverait "cpu.frequency", qui contiendrait les valeurs "1Ghz, 2Ghz et 3Ghz".
 
 \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 collisionne pas.
+\subsubsection{Choix dans une liste} cette méthode est surtout utilisée par les systèmes qui supportent uniquement la réservation d'instances en faisant abstraction du matériel. Ceux-ci n'ont pas besoin de donner à l'utilisateur la possibilité de choisir les caractéristiques de son hôte physique, car cela n'a pas d'importance. L'utilisateur choisit parmi une liste de flavor (CPU, mémoire, disque), et l'ordonnanceur trouve ensuite un hôte capable de supporter cette flavor (OpenStack).
 
-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 d'une 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'étendre après coup sa période de réservation, s'il s'aperçoit que sa tâche n'est pas finie lorsque sa réservation va arriver à échéance.
+Cette méthode est aussi utilisée par les fournisseurs qui proposent un choix restreint d'hôtes physiques différents (OVH).
+
+\subsubsection{Construction d'une expression des prérequis} cette méthode est surtout utilisée par les systèmes ouverts (Grid'5000), et dans lesquels les utilisateurs veulent choisir précisément leurs machines. Cependant, OpenStack supporte cette fonctionnalité grâce à des filtres, qui permettent de filtrer sur des propriétés matérielles plus précises, telles que les CPU infos.
 
-% 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), et composer une expression, dont la grammaire s'inspire de celle du 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 HPC, 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 sélectionnées sont homogènes en performances au sein de chaque groupe, mais hétérogènes en performances entre groupes différents.
+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), et composer une expression en utilisant des opérateurs logique. Cependant, dans un contexte HPC, les applications sont sensibles aux disparité de performances entre les noeuds. Il serait nécessaire de pouvoir exprimer ce besoin, sans pour autant donner obligatoirement une valeur.
+Par exemple, un utilisateur peut vouloir n'importe quel fréquence de processeur, pourvu qu'elles soient toutes les mêmes.
 
-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. Les réservations immédiates sont supportées (il s'agit juste d'un cas particulier).
+Ce besoin d'homogénéité s'applique généralement aux CPUs et GPUs, et carte réseau, car ces propriétés dégradent la performances des applications distribuées si elles ne sont pas homogènes. Une quantité de mémoire homogène peut également être importante, dans la mesure où cela facilite le travail du développeur, qui optimise son application pour une taille de mémoire donnée. Mais si un noeud a plus de mémoire qu'un autre, l'application n'ira pas plus vite, ce sera juste de la mémoire inutilisée et "gaspillée".
 
-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.
+\subsection{Types de réservations}
+Le type de réservation dépendra du cas d'usage.
 
-Enfin, l'utilisateur peut préciser sur quel 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.
+Les réservations immédiates doivent être honorées immédiatement, ou pas du tout.
 
-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.
+Les réservations en avance doivent commencer et terminer à des heures spécifiques.
 
-\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}
+Les réservations best effort sont placées dans une file, et honorées dès que possible. On peut imaginer des options : deadline, tarif degressif.
+Elle peuvent être non-préemptables ou préemptables. Dans ce cas, elles peuvent être interrompues s'il y a des réservations plus urgentes (immédiates ou en avance). Une réservation interrompue est soit migrée vers un autre hôte (à chaud ou à froid), soit suspendue puis relancée sur le même hôte, soit tuée (c'est alors à l'application de checkpointer).
+
+Le système supporte aussi les instances non-réservées (comme cela existe dans Nova actuellement).
+
+\subsection{Ajout dynamique de ressources à la réservation}
+Au moment de la réservation, l'utilisateur précise le nombre la quantité de resources nécessaire.
+Mais au cours de la réservation, ses besoins peuvent évoluer. Il doit pouvoir ajouter des ressources ou en supprimer, à la volée.
+Le prix horaire de ces ressources supplémentaire sera plus élevé que les ressources réservées en avance (pour inciter l'utilisateur à estimer au plus juste la quantité de ressources nécessaires).
 
-\subsection{Modèles de réservation}
+\subsection{Affectation des hôtes physiques à la 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.
 
 % TODO pro / cons
@@ -187,14 +145,39 @@ La deuxième stratégie est plus robuste à ce niveau là : en cas de panne d'un
 
 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{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 la taille et les caractéristiques de 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.
+Avant le début de réservation, plus l'utilisateur l'annule tôt, mieux il sera remboursé. Cependant, si l'utilisateur l'annule immédiatement après avoir réservé, le taux de remboursement est moins de 100\% pour éviter qu'il ne fasse des reservations multiples.
+Une fois la réservation démarrée, si l'utilisateur l'annule, il est remboursé sur la base de la période qui n'a pas été consommée. Le taux de remboursement est fixe (par exemple 75\%). L'utilisateur pourrait récupérer son argent, mais il semble plus judicieux de lui rembourser sous forme de crédits qu'il pourra utiliser lors d'une prochaine réservation.
+
+\subsection{Facturation des réservations}
+Les réservations, en garantissant un environnement single-tenant, permettent une facturation à l'usage précise et incontestable.
+En effet, sur les environnements multi-tenant, il est difficile de répartir le coût statique des machines : les clients seuls sur une machine seraient défavorisés par rapport à ceux qui se partagent un même machine. En effet, le coût statique d'une machine étant invariable, plus il y a d'utilisateurs par machine, plus la part de coût statique par utilisateur est bas.
+
+La facturation prend en compte une part statique, qui est facturée au moment de la réservation, et une part dynamique calculée une fois la réservation terminée, et qui varie selon l'énergie consommée (kWh consommés multipliés par le coût du kWh). Cela incite les clients à optimiser leurs programmes, et permet une facturation équitable des clients.
+
+\subsubsection{Part statique}
+\paragraph{Type de réservation} les réservations immédiates sont les plus chères, et les best efforts les moins chères. Les réservations en avance pourront avoir un tarif dégressif, par tranche de temps : par exemple la première semaine coûtera un peu plus cher que la seconde semaine, et ainsi de suite.
+
+\paragraph{Performance des machines} les machines les plus performantes doivent coûter plus cher, car elles sont plus récentes, plus onéreuses, terminent plus rapidement les tâches soumises et sont très souvent utilisées pour des applications urgentes. Ainsi, pour un même ratio Flops/W, la machine la plus rapide devra coûter plus cher.
+
+\subsubsection{Part dynamique}
+\paragraph{Utilisation des ressources} grâce à un service de réservation, le DCIM peut faire des prévisions d'usage du datacenter, 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 maximum 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 ?
+
 \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.
+\subsubsection{Algorithme first-fit}
+L'algorithme first-fit est basique et rapide. Il 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.
 
+\subsubsection{Algorithmes avancés}
 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.
 
+\subsubsection{Solutions multiples et suggestions}
 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 peut conduire à dévoiler un peu l'usage du datacenter.
 
@@ -204,25 +187,119 @@ Cependant, ce mécanisme de suggestion est le moins utilisé sur les plateformes
 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 la taille et les caractéristiques de 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.
-Avant le début de réservation, plus l'utilisateur l'annule tôt, mieux il sera remboursé. Cependant, si l'utilisateur l'annule immédiatement après avoir réservé, le taux de remboursement est moins de 100\% pour éviter qu'il ne fasse des reservations multiples.
-Une fois la réservation démarrée, si l'utilisateur l'annule, il est remboursé sur la base de la période qui n'a pas été consommée. Le taux de remboursement est fixe (par exemple 75\%). L'utilisateur pourrait récupérer son argent, mais il semble plus judicieux de lui rembourser sous forme de crédits qu'il pourra utiliser lors d'une prochaine réservation.
+\section{Architecture d'efficience énergétique}
+L'architecture d'efficience énergétique met à disposition du scheduler les informations nécessaires pour prendre ses décisions de placement.
 
-\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 machine virtuelle, 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.
+\subsection{Kwapi}
+Kwapi is our framework, designed for acquiring energy consumption metrics. It allows, among other, to upload metrics from the wattmeters to Ceilometer.
 
-La facturation prend en compte une part statique, qui est facturée au moment de la réservation, et une part dynamique calculée une fois la réservation terminée, et qui varie selon l'énergie consommée (kWh consommés multipliés par le coût du kWh).
+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 checking 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 probe names, and W, kWh or 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 après leur 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 tendance à mettre en veille 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 son indice de performances, et de sa consommation minimum, moyenne et maximum.
+
+\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 n'a besoin de se faire 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.
+
+\subsection{Modes de veille}
+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 instance 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, plus cela met du temps à rallumer la machine et plus cela est coûteux en terme d'énergie.
+% TODO REF
+On notera qu'il ne semble pas préjudiciable à la durée de vie des machines de les éteindre et rallumer fréquemment (selon REF).
 
-La part statique est basée sur les paramètres suivants :
 
-\paragraph{Performance des machines} les machines les plus performantes doivent coûter plus cher, car elles sont plus récentes, plus onéreuses, et sont très souvent utilisées par les applications qui requièrent des réservations urgentes. Ainsi, pour un même ratio Flops/W, la machine la plus rapide devra coûter plus cher.
 
-\paragraph{Charge} grâce à un service de réservation, le DCIM peut faire des prévisions d'usage du datacenter, 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 maximum 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 ?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+% 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 collisionne 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 d'une 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'étendre après coup sa période de réservation, s'il s'aperçoit que sa tâche n'est pas finie lorsque sa réservation va arriver à échéance.
+
+% TODO donner un exemple d'expression
+
+
+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. Les réservations immédiates sont supportées (il s'agit juste d'un cas particulier).
+
+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 quel 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}
+
 
 % TODO Scénarios et validation.
 
@@ -314,10 +391,10 @@ Cette API est sécurisée par l'emploi des tokens Keystone. Selon le rôle corre
 \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\\
+POST & /reservations/ & Creates a reservation\\
+GET & /reservations/ & Lists the reservations\\
+GET & /reservations/<réservation-id> & Describes a reservation\\
+DELETE & /reservations/<réservation-id> & Cancels a reservation\\
 \hline
 \end{tabular}
 \end{table}
@@ -328,15 +405,6 @@ Les hôtes candidats sont ceux qui matchent les propriétés requises par l'util
 
 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 instance 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, plus cela met du temps à rallumer la machine et plus cela est coûteux en terme d'énergie.
-% TODO REF
-On notera qu'il ne semble pas préjudiciable à la durée de vie des machines de les éteindre et rallumer fréquemment (selon REF).
-
 \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.
 
@@ -358,51 +426,18 @@ Le second pondérera les machines en fonction de leur efficacité énergétique.
 
 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 checking 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 probe names, and W, kWh or 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).
+\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.
 
-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 après leur 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 tendance à mettre en veille ceux qui consomment le plus.
+% TODO difficulté à évaluer la durée d'une tâche
+% 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 sélectionnées sont homogènes en performances au sein de chaque groupe, mais hétérogènes en performances entre groupes différents.
 
-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 son indice de performances, et de sa consommation minimum, moyenne et maximum.
 
-\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 n'a besoin de se faire 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.
 
-\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, ou honorer une requête trop contraignante. Cependant, il ne faut pas révéler trop d'éléments sur le datacenter.
 
