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

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. 

\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.

Ce type d'instances est généralement proposé par les fournisseurs de clouds (Windows Azure, etc).

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).

À notre connaissance, seul Amazon EC2 supporte cette fonctionnalité.

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".

\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).

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.

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.

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".

\subsection{Types de réservations}

Le type de réservation dépendra du cas d'usage.

Les réservations immédiates doivent être honorées immédiatement, ou pas du tout.

Les réservations en avance doivent commencer et terminer à des heures spécifiques.

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{Affectation des hôtes physiques à la réservation}

\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 ?

\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}

\subsubsection{Solutions multiples et suggestions}

\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{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).

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).

% 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}

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\\

\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.

% 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.