Programmation modulaire : les vues

Les vues sont, d’un point de vue administrateur, de nouvelles règles que l’on veut ajouter au cœur minimal. Ces règles peuvent porter sur les VM, sur les serveurs comme celles déjà présentes dans ENTROPY, ou éventuellement sur des entités spécifiques à une vue. Elles doivent être respectées dans la configuration fournie par OPTIPLACE.

En plus des règles, une vue peut apporter une notion de coût de solution à réduire lors de la recherche d’une solution à un problème. Ce coût est une fonction mathématique à minimiser lors de cette recherche, et modélisée à partir des variables du problème. Par exemple, dans ENTROPYV2.0 l’objectif était de minimiser le nombre de migration dans le plan de reconfiguration.

Ces vues étendent le cœur minimal d’OPTIPLACE, en ajoutant de nouvelles données au problème initial de placement. Typiquement la vue énergétique ajoute, en plus des spécifications des ressources du centre, des modèles de consommation électrique de ces serveurs en fonction de la consommation des ressources des VM qu’ils hébergent. Elle est utilisée comme une extension de la configuration virtuelle, ajoutant ses variables, contraintes, et coûts au problème de placement. Ainsi une vue s’appuie sur les quatre piliers de la PPC : les variables du problèmes, les plages de valeur de ces variables, les contraintes entre ces variables, et les potentielles fonctions de coût à minimiser.

La première vue HD a principalement demandé un travail de ré-architecture. Cette vue n’étend pas la configuration initiale, car elle n’apporte pas de données supplémen- taires au modèle initial. Elle donne accès à des règles de placement : spread, group, ban, fence, issues des travaux sur ENTROPYV2.0. Dans le cas où ou le système recherche un placement valide pour toutes les VM, il n’y a pas de fonction de coût associé. Cependant dans le cas où le système cherche à réduire le nombre de migrations, le vue HD propose (importé d’ENTROPY V2.0) une fonction de coût qui est le nombre total de migrations à effectuer pour passer de la configuration initiale à la solution. L’intérêt de cette vue

66 CHAPITRE 4. OPTIPLACE HA consiste plus en son apport architectural que dans ses fonctionnalités, qui sont les mêmes que celles présentes dans ENTROPYV2.0.

Concernant la vue énergétique, un travail de recherche et d’évaluation plus important à été nécessaire, décrit dans la section correspondante 4.3.

Utilisation par l’administrateur

Un administrateur utilise OPTIPLACEpour maintenir son centre dans un état satisfai- sant. Cette notion de satisfaction est intrinsèque au centre considéré, en effet chaque centre possède ses règles spécifiques. Le problème du placement des VM dans un centre doit donc être paramétré par l’administrateur pour prendre en compte ces spécificités.

La configuration virtuelle du centre, c’est-à-dire les listes de VM, serveurs et les allocations des VM sur les serveurs, peut être généralement obtenue par le système de gestion du centre. Cependant, les demandes spécifiques de l’administrateur, telles l’arrêt d’un serveur ou la réduction des points chauds du centre, ne sont pas connues par de tels systèmes de gestion. De même, les utilisateurs du centre peuvent spécifier des demandes à prendre en compte par l’administrateur, telles la création d’une nouvelle VM ou l’augmentation des capacité en mémoire d’une VM existante.

Le système de vues permet, une fois paramétré, de prendre en compte ces demandes spécifiques sous la forme de règles à injecter dans un problème de placement. OPTI- PLACE permet à l’administrateur d’un centre d’ajouter des règles de fonctionnement et de préciser un objectif à atteindre, sous la forme d’une fonction de coût. Pour cela, les vues doivent tout d’abord obtenir les données propres à leur domaine. Une fois cor- rectement configurées, les vues sont utilisées pour chaque problème de placement dans un centre. À chaque fois qu’OPTIPLACEdoit résoudre tel problème, les vues activées par l’administrateur injectent leurs règles dans le cœur du problème. Par exemple, si la vue énergétique est activée, elle peut ajouter ses modèles de consommation des ser- veurs dans le problème. En particulier, ce sera le cas si l’administrateur veut réduire la consommation du centre ou de certains serveurs.

Le paramétrage des vues, en particulier l’obtention des données propres à leur do- maine, est une opération à la charge de l’administrateur.

Intégration des vues à la résolution d’un problème

Le processus de résolution d’OPTIPLACE, présenté dans la figure 4.2, est le suivant : Tout d’abord, OPTIPLACEnécessite de connaître la configuration virtuelle du centre, tel que décrite plus haut. Il peut ainsi modéliser en interne cette configuration, c’est-à- dire le cœur du problème de placement des VM sur les serveurs. Cette information est typiquement obtenue parBTRCLOUDaprès traduction des indications des gestionnaires dans le modèle d’OPTIPLACE, via son API.

4.2. OPTIPLACE 67 Une fois le cœur du problème créé, celui-ci est enrichi des spécifications de res- sources. Ces spécifications sont fournies par les vues et décrivent les capacités des ser- veurs et les consommations des VM pour chaque ressource. Des fonctionnalités dédiées réduisent la charge de développement inhérente à l’ajout d’une ressource.

Les vues paramétrées par l’administrateur sont ensuite associées au problème. Celles- ci accèdent ainsi aux données du problèmes et ajoutent leurs variables et contraintes dans ce dernier. Par exemple, la vue énergétique utilise les variables d’utilisation des ressources des serveurs pour créer et contraindre des variables de consommation élec- trique.

Une fois ces vues associées, leurs règles sont injectées dans le problème. Ces règles sont appliquées aux variables du problème, que ce soit celles crées par le cœur ou par les vues, en ajoutant des contraintes dans le cœur du problème. Par exemple le bannis- sement d’un serveur, demandé par l’administrateur pour des raisons de maintenance, contraint le nombre de VM hébergées sur un serveur à être zéro.

Enfin, une fois les règles injectées dans le problème, l’objectif de recherche (c’est- à-dire le coût à réduire) est déterminé et utilisé dans la résolution du problème. Cette résolution consiste en la recherche d’un état du centre qui respecte les règles des vues, tout en minimisant le coût spécifié. Quand le solveur à déduit du problème une solution, les vues utilisées en déduisent les résultats qui leurs sont propres. Par exemple, la valeur de consommation totale des serveurs du centre est déduite par la vue énergétique, la seule à avoir connaissance du sens de cette valeur.

68 CHAPITRE 4. OPTIPLACE problème initial configuration vir- tuelle du centre injection des spécifications de ressources vues du pro- blème

associer les vues au problème ajout des contraintes administrateur contraintes de l’administrateur résolution du problème dans Choco spécification du coût et para- mètres de re- cherche traduction de la solution

FIGURE4.2 – Processus d’utilisation d’OPTIPLACE.

Ainsi, les vues exposent leurs variables et contraintes, qu’elles les utilisent directe- ment ou que celles-ci soient utilisées par d’autres vues, tout en proposant à l’adminsi- trateur des méthodes pour enrichir le problème de placement.

L’avantage de cette modularité est que les paramètres du problème et les règles de différentes vues peuvent être incorporées simultanément dans un problème. Il est donc possible de développer une nouvelle vue sans aucune connaissance des vues dévelop- pées précédemment ou même activées dans le système, et par la suite de changer une vue pour une version plus à jour sans modifier les autres vues ni les paramètres d’exécution du problème.

Cette fonctionnalité apporte la flexibilité nécessaire à un outil de placement intelli- gent et efficace.

Intégration des vue dans OPTIPLACE

Le cœur d’OPTIPLACEpermet de définir la configuration virtuelle d’un centre, les para- mètres de résolution d’un problème, et présente les fonctions d’extension par des vues. Les vue peuvent s’appuyer sur d’autres vues pour s’intégrer dans un problème. Ainsi, la vue thermique, qui modélise le coût de la climatisation, nécessite des modèles de consommation des serveurs apportés par la vue énergétique . Lorsqu’un développeur

4.2. OPTIPLACE 69 améliore la vue énergétique, ces améliorations sont apportées à la vue thermique sans avoir besoin de modifier cette dernière. Pour cela, chaque vue doit présenter de manière explicite les variables qu’elle ajoute au problème, ainsi que les contraintes qu’elle peut générer.

En suivant ces besoin, nous avons développé OPTIPLACE pour que les vues ac- cèdent dans le cœur d’un problème à des fonctions communes de création de variables et de contraintes. Une fois paramétrée, une vue est alors indépendante d’un quelconque problème de placement, bien qu’elle soit basée sur une première configuration virtuelle. C’est pourquoi, lors de la résolution d’un problème, chaque vue activée est associée au cœur de ce problème. Une fois associée, une vue a accès aux variables du cœur du problème, ainsi qu’aux fonctions précédemment décrites. Elle peut alors utiliser ces dernières pour intégrer ses règles, sous formes de contraintes, au problème.

En plus des contraintes à satisfaire, les vues peuvent spécifier une fonction de coût à minimiser lors de la résolution d’un problème. Une telle fonction de coût est intégrée dans un problème de placement par la création d’une variable correspondante dans le problème.

Ces fonctionnalité d’injection de règles, de spécification des ressources et de sélec- tion d’un coût dessinent les traits d’une architecture réflexive. Cette capacité des vues à changer le modèle interne ne se limite pas à l’ajout de variables et contraintes, mais aussi à l’accès à des paramètres plus poussés de recherche de solution.