/papers/2013/Climate-Paper/paper.tex - Diff - XLcloud - Forge du Centre Blaise Pascal

Révision 5a976f8f papers/2013/Climate-Paper/paper.tex

     \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{Climate: Resource reservation\\service for OpenStack}
     \title{Improving HPC support in OpenStack\\by introducing a resource reservation service}
     \author{
       \IEEEauthorblockN{François Rossigneux}
-...
     \maketitle
     % Intro
     %   Avenement du cloud, mais certains aspects restent en rade => besoin de la réservation.
     % - Des scénarios nouveaux
     % - Émergence de nouveaux modèles de facturation
     % - Expression des besoins (hardware, network, mais aussi latence, etc opérateurs, homogeneous)
     % - Dévoiler ou pas ? Optimiser le scheduling ? Sugérer ?
     % - Qu'est-ce qu'une réservation ? À quoi est-ce limité ? Comment identifier les resources ? Soft ou hard allocation ?
     % - Une extension de l'architecture d'OpenStack
     % - De nouvelles possibilités en terme d'énergie (billing, mais aussi sleeping)
     %  Conclu
     % Nouveaux éléments
     % - Réservation latence réseau
     % - Sous-providers
     % - Plateforme ouverte vs fermée
     % - Dévoiler plus ou moins de choses
     % - Réserver des autres resources
     % - Réserver au début ou à la fin
     % - Migration VMs
     % - Annulation dégressive, modèles de facturation.
     % - Acquisition des métriques (dyn, sta ?)
     % => INNOVATION dans OpenStack
     % Faut-il parler du projet XLcloud ?
     % TODO: réorganiser un peu l'enchainement des idées, mais l'essentiel est là.
     \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.
     % dont le résultat est injecté dans Nova sous forme de hint. Climate est ensuite requêté par Nova grâce aux extensions filters, qui permettent le lancement de filtres personnalisés. Le choix des machines réservées se fait en tenant compte aussi de leurs performances énergétiques. C'est pourquoi Climate et Nova s'interfacent avec Kwranking, le module d'efficience énergétique qui exploite les métriques remontées par Kwapi (le module de télémétrie) et calcule un indice de performance énergétique en flops/w. Climate, comme il dispose d'un calendrier des réservations, permet de mettre en veille les machines durant les périodes d'inactivité.
     \end{abstract}
     \section{Introduction}
     % NEW
     Avec l'avènement du cloud et la mutualisation des équipements, les utilisateurs sont amenés à partager la même infrastructure. Cette consolidation apporte bien des avantages, en terme d'efficacité énergétique notamment, puisque le taux d'utilisation des machines est plus élevé, et de souplesse d'utilisation, les entreprises n'ayant plus besoin d'héberger elles mêmes leurs infrastructures informatiques, qui étaient par ailleurs souvent surdimensionnées.
     Ce nouveau modèle convient à la plupart des usages, mais certains domaines, telle que le HPC, sont difficilement transposables dans le cloud sans nécessiter quelques adaptations.
     Étant donné que les jobs HPC sont très intensifs, il est nécessaire d'optimiser l'infrastructure pour rendre possible leur exécution dans un délai raisonnable. La communication entre les machines doit avoir une faible latence, et les noeuds de calcul doivent être suffisament homogènes pour éviter que le plus lent ralentisse les autres.
     Il faut aussi veiller à ce que l'activité des autres utilisateurs ne perturbe pas les jobs HPC.
     Pour faire face à ces contraintes, et conjuguer les avantages du cloud avec les performances offertes par une infrastructure privée, il est nécessaire de pouvoir réserver des ressources. Ces ressources, dans un contexte HPC, seront intensivement utilisées. Ne se posent donc pas les inconvénients d'une mauvaise consolidation (mauvaise efficacité énergétique, gaspillage de ressources).
     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 open source de cloud qui connait une forte croissance actuellement, ne dispose pas d'un service de réservation. Les instances de VMs sont instanciées immédiatement.
     D'une part, ce modèle se prête mal au HPC, et d'autre part, cela empêche le gestionnaire de datacenter (DCIM) de pouvoir prévoir l'utilisation future des resources, et par conséquent de pouvoir lisser la charge du datacenter en proposant un modèle de facturation attractif qui incite les utilisateurs à réserver durant les périodes moins chargées, ou sur du matériel plus efficient.
     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 MAJ en fonction de la suite...
     Dans ce papier, nous proposons donc un service de réservation pour OpenStack, qui permette de supporter les scénarios de type HPC. Dans une première partie, nous verrons quels scénarios seraient rendus possibles par un tel service. Ensuite, nous verrons en détail comment l'utilisateur pourra exprimer ses besoins, quel sera le fonctionnement du scheduler, et comment le placement des réservations pourra être optimisé.
     % 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.
     % OLD
     % Avec l'avènement du cloud, beaucoup d'environnements mono-tenancy sont passés en multi-tenancy. Cependant, au-dela des avantages indéniables que présente la mutualisation des équipements, se posent de réels challenges pour migrer des environnements de type HPC dans le cloud. En effet, dans un environnement multi-tenancy, il n'y a aucune garantie que la performance soit lisse dans le temps (charge parasite et trafic réseau parasite), et souvant, le modèle de réservation de ces environnements ne garantie pas la réservation de noeuds avec des performances homogènes (les machines les plus rapides peuvent être potentiellement freinées par les plus lentes). Le critère d'homogénéité d'un groupe de machine sera la vitesse CPU/GPU, et la carte réseau. En effet, si un hôte a plus de mémoire que nécessaire, cela n'a pas d'impact sur les performances.
     \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.
     % Aujourd'hui, deux modèles se cotoient: les environnements multi-tenancy, sans réservation à l'avance (type OpenStack), et mono-tenancy, avec une réservation à l'avance (type Grid'5000, plateforme d'expérimentation scientifique).
     % Le projet XLcloud vise à faire converger ces deux mondes, et comme il repose sur OpenStack, nous avons vu le besoin d'y ajouter un service de réservation de ressources. Il permettra la réservation des resources dans le temps, en essayant de minimiser la consommation d'énergie. Il permettra à Nova retrouver les hôtes réservées. La base de réservation pourra être exploitée pour la facturation (on est capable de dire quel utilisateur possédait telle machine à un instant donné), et permettra d'optimiser la consommation d'énergie en éteignant les machines qui ne sont pas susceptibles d'être utilisées prochainement.
     \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.
     % % Need to be updated
     % Dans une première partie, nous décrirons l'architecture globale, avec d'une part les modules de réservation et de scheduling (Climate et Nova), et d'autre part la remontée des métriques énergétiques et leur exploitation. Ensuite, nous montrerons comment ces modules s'interconnectent, afin d'améliorer l'efficacité énergétique, grâce à une réservation plus judicieuse des resources, et un meilleur contrôles des hôtes en marche et en veille. Enfin, nous parlerons des performances et limitations du modèle actuel.
     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.
     \section{Scénarios envisagés}
     \subsection{Provider spécialisé HPC}
     Nous pouvoir 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é.
     % 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.
     % Climate peut servir à des entreprises, qui louent une partie des ressources ayant certaines propriétés et les louent ensuite à leurs clients.
     % Par exemple, un provider spécialisé dans le HPC pourrait louer des noeuds avec des propriétés bien définies en termes de latence maximale entre les noeuds.
     % Il créerait une réservation pour une période d'un an, et les utilisateurs chargeraient automatiquement leurs instances dans cette grosse réservation.
     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.
     % TODO parler des problèmes ?
     % Ce schénario se rapproche d'une réservation permanente. En effet, il est probable que le provider HPC veuille poursuivre sa réservation arrivé à l'échéance. Sauf qu'il peut y avoir une autre réservation de placée. Climate pourrait supporter ce type de réservation, si on omettait la date de fin et la duration. Ce type de réservation devra être manuellement annulé.
     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{Optimisation 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.
     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.
     % TODO dévoiler charge ?
     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 ?
     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.
     \subsection{Facturation à l'usage}
     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 qu'il a consommé telle quantité d'énergie, 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.
     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.
     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.
     \section{Modèle de réservation}
     Nous proposons un modèle de réservation qui permettent à l'utilisateur de préciser des critères sur la réservation : 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 qui importent. Cela permet au scheduler de trouver le meilleur moment où réserver les ressources. Pour une réservation immédiate, il suffit fixer les bornes de début et de fin de façon adéquate.
     Les propriétés que passent l'utilisateur en paramètre serviront à trouver quels hôtes correspondent à ses besoins. Dans un contexte HCP, les applications sont sensibles aux disparité de performances entre les noeuds. C'est pourquoi l'utilisateur aura besoin de noeuds aux performances de calcul homogènes (en terme de CPU ou GPU, et communication réseau). Mais parfois, le modèle de CPU spécifique n'importe pas. Il faut donc introduire un mot clé "homogeneous" que l'utilisateur peut utiliser pour demander à ce que tous ses noeuds soient homogènes sur le critère spécifié.
     L'homogénéité des machines en terme d'espace mémoire ou de stockage n'a pas d'importance, pourvu que cet espace soit suffisant. Effet, si un hôte a plus de mémoire qu'un autre, il n'ira généralement pas plus vite.
     Une réservation est une attribution de machines entre deux dates, à un client (project dans OpenStack).
     Cependant, il convient 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 disponbibles. Cette approche permet une facturation des réservations qui est dégressive en fonction de l'anticipation (plus on anticipe, moins c'est cher).
     \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.
     Cependant, 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 correcpondant à 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.
     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é par les utilisateurs.
     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.
-...
     \hline
     \bfseries Method & \bfseries URL & \bfseries Description\\
     \hline
     POST & /réservations/ & Creates a réservation\\
     GET & /réservations/ & Lists the réservations\\
     GET & /réservations/<réservation-id> & Describes a réservation\\
     DELETE & /réservations/<réservation-id> & Cancels a réservation\\
     \hline
     \end{tabular}
     \end{table}
     \begin{table}
     \renewcommand{\arraystretch}{1.3}
     \caption{réservation creation arguments}
     \label{climate_creation_arguments_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 & réservation duration \\
     quantity & Number of hosts \\
     host\_properties & Criteria to select the hosts \\
     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}
-...
     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 faudrait fournir un catalogue des propriétés que l'on peut trier, et éventuellement construire une couche d'abstraction si on veut permettre le filtrage sur d'autres propriétés que celles retrouvées dans les détails de l'hôte, sur Nova.
     \subsubsection{Scheduler}
     Le rôle de Climate Scheduler est de trouver quels sont les emplacements libres pour placer une réservation.
     Il prend en entrée les arguments qu'à fournis l'utilisateur à Climate API, à l'exception des host\_properties qui sont remplacées par la liste des hôtes candidats retrouvés par Climate Inventory.
     Le scheduler 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.
     % TODO: insertion de l'algo de FULL, FREE, PROPOSAL.
     Il serait souhaitable d'étendre les possiblités de ce scheduler, qui actuellement place les réservations au plus tôt. On pourrait optimiser le placement des réservations pour minimiser le nombre d'extinction redémarrage (aggrégation possiblement à la fin plutôt qu'au début). D'autre critère pourraient jouer, comme le coût de l'énergie. Par contre, cela pourrait se traduire par une complextité de recherche des réservations plus grande.
     Lorsque plusieurs choix sont possible, le scheduler n'en retourne qu'un, pour éviter de dévoiler l'usage du datacenter.
     \paragraph{Suggestions}
     Certaines plateformes sont totalement ouvertes. De ce fait, un mécanisme de suggestion est superflu.
     D'autres sont fermées, et un mécanisme de suggestion serait très utile pour éviter de rejeter des demandes utilisateurs, ou simplement proposer un meilleur placement de réservation, qui arrange à la fois l'utilisateur et le provider.
     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.
     Dans ce type de plaforme, il faut donc se prémunir de ce type d'attaque, en fixant des limites aux valeurs extrêmes des paramètres, et en limitant le nombre de requête par seconde. On ne peut pas facturer la tentative de création de réservation, en revanche.
     \paragraph{Annulation}
     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\%.
     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.
     Cela nous amène à parler des réservations à profil variable : au cours d'un calcul, on peut imaginer que le nombre de resources nécessaire varie fortement. 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, au cours d'une réservation, d'aggréger d'autres hôtes à sa réservation, selon ses besoins.
     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 à l'instant T. Seuls les hôtes qui ne sont pas dans cette liste sont éligibles.
     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 X hôtes les plus efficients.
     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. In the case of a distributed architecture, a plugin can listen to several drivers at remote locations (see Figure \ref{fig_architecture}).
     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.
-...
     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.
     % Kwranking écoute le bus Ceilometer, entre le pollster et le Collector. Et crée une base de donnée.
     % L'efficacité des machines, dans notre modèle, se calcul en fonction de la performance, et de la conso.
     % La performance peut être estimée soit à partir d'un benchmark, mais cela est contraignant, soit à partir des CPU info.
     % Pour cela, l'API de Nova expose des CPU info. On prend en compte la famille du processeur, et le nombre de sockets, core, threads, et aussi de la fréquence / mémoire cache.
     % L'idée d'exploiter les bogomips est mauvaise car ils ne sont pas significatifs, et dépendent de l'optimisation du jeu d'instruction du processeur.
     % Le modèle pourra ensuite être complexifié pour tenir compte de la présence de GPUs.
     % Il faudrait aussi tenir compte du temps et de l'énergie nécesaire pour atteindre les différents niveaux de veille.
     % Et également du cycle de vie des machines.
     \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.
-...
     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 d'ordres stratégique, et celles portant sur des éléments techniques susceptibles d'évoluer.
     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.
     Plusieurs zones d'ombres subsistent :
     - Dans l'inventaire, on se base sur le host id, qui semble être la référence des hyperviseurs. Mais dans les filtres Nova, c'est l'hostname qui est utilisé. Du coup, à qui faut-il faire confiance ? Le plus simple serait de retrouver l'ID à partir du hostname dans le filtre Nova, mais comment ?
     - L'inventaire, comme il n'a pas de database, doit contacter Nova à de nombreuses reprises.
     Une fois pour avoir la liste des hôtes, puis une fois pour chaque hôte (complexité = 2*N).
     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.
     - Pour filtrer sur les propriétés, on utiliser le json filter extrait de nova.
     Il supporte l'imbrication à 2 niveaux seulement, me semble-t-il.
     L'idéal serait d'avoir un service qui expose un catalogue de properties, que l'utilisateur peut consulter pour élaborer des filtres complexes.
     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.
     De plus, le filtre actuel ne supporte pas la fonction "homogeneous". En effet, un utilisateur peut vouloir des hôtes peu importe leurs performances, mais l'important c'est qu'il soient homogènes. Trop de mémoire ce n'est pas gênant. Mais un CPU ou un network card hétérogène peut être embêtant... Du coup, quel est le critère d'homogénéité (CPU + network ???).
     - Le filtre Nova effectue de nombreuses requêtes. Il faudrait qu'il puisse demander "quels sont les hôtes non réservés ? " à Climate.
     S'il n'y a plus assez de machines libres pour honorer une demande de réservation, les VMs pourraient être migrées et aggrégées afin de libérer de la place.
     Pour cela, il faut faire de groupe de réservations qui ont besoin du même type d'hôtes.
     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.
     % \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}
     Climate supporte actuellement la réservation de noeuds entiers, ce qui est utile dans un contexte HPC.
     Mais nous pourions généraliser ce système de réservation de resources à d'autre éléments, à plus fine granularité : réservation de CPU, de mémoire, etc.
     Il faut aussi déterminer si les ressources sont choisies au moment de la réservation, ou si elles sont simplement décomptés des resources disponibles (assignation du matériel à la réservation ou à l'instanciation de machines virtuelles).
     L'API de Climate pourrait, à terme, être fusionnée à Nova. En effet, Nova ne supporte que le lancement d'instances immédiates, et la réservation à l'avance de resources pourrait être intéressante. Actuellement, les resources réservées sont des hôtes, mais peut-être certains use-case seraient intéressés par la réservation de resources à fine-granularité (CPU, RAM, etc).
     Climate pourrait supporter plusieurs algorithme de scheduling (comme dans Nova, où il est possible de préciser des filtres personnalisés dans le fichier de configuration). On pourrait même imaginer la possibilité pour l'utilisateur de choisir son algo de placement, pour optimiser tel ou tel critère. Ou alors créer des policies pour appliquer tel ou tel algo de placement à tel ou tel utilisateur.
     Actuellement, les machines sont triés par efficacité énergétique en prenant en compte leur CPU. Il pourrait être intéressant d'ajouter d'autres critères, comme le GPU, etc. Mais cela demanderait de connaître quelle est la part d'énergie imputée à tel ou tel composant.
     Le calendrier de réservation pourrait être managé par le DCIM: il pourrait faire du power capping en considérant comme pleine certaines périodes de réservations (pour cela on fait la somme de la conso de toutes les machines réservées à un instant donné).
     Et au moment de la réservation, un pondérateur pourrait pondérer les périodes de réservation en fonction du coût du courant.
     De ce fait, l'architecture de Climate doit être très modulaire, avec la possibilité de pluger ses propre plugins.
     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}

Formats disponibles : Unified diff

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

Révision 5a976f8f papers/2013/Climate-Paper/paper.tex