L’informatique dans les nuages
Depuis la fin du siècle dernier, l’utilisation de l’outil informatique a suivi une augmentation fulgurante, tant par le grand public que par les entreprises. Les utilisations de cet outil se sont multipliées, au point de le rendre indispensable dans la société actuelle. La messagerie en ligne, les réseaux sociaux, la modélisation météorologique, la simulation des réactions nucléaires, l’analyse des tendances d’un marché, la gestion économique d’une entreprise, l’achat en ligne, la publication de contenu multimédia etc. sont des utilisations dorénavant quotidiennes de l’outil informatique. En particulier, l’utilisation de services à distancce s’est fortement développée, rendant l’accès à internet nécessaire pour beaucoup d’utilisations de l’outil informatique. Chacun de ces services à distance nécessite l’administration et la maintenance de leur puissance de calcul respective. Cette puissance de calcul est présente physiquement sous la forme de serveurs informatiques. Ceux-ci exécutent, dans un environnement logiciel appelé OS, les programmes nécessaires pour fournir les services demandés. Le besoins en services informatiques étant en augmentation, les entreprises prestataires de ces services ont alors accru leur capacité de traitement. Cet accroissement a été réalisé via l’augmentation de la taille de leur parc de serveurs, mais celle-ci fit apparaître des problèmes liés au changement d’échelle. Par exemple, les problématiques liées au stockage des données, à la sécurité du matériel et à la résilience des services nécessitent des soins particuliers. Ces entreprises sont amenées à investir massivement dans des salles dédiées à l’exécution des tâches informatiques. Ces salles sont communément appelées centres de traitement des données, et peuvent comporter des milliers de serveurs. Elles sont aménagées de manière à installer et administrer facilement non seulement les serveurs, mais aussi le matériel utilitaire du centre (switch, climatisation, etc.). Cependant, l’accroissement du nombre de serveurs dans ces salles soulève à son tour de nouvelles problématiques, telles la dissipation de la chaleur ou la question du taux d’humidité dans l’air. Du fait de la diversité des contextes de l’informatique industrielle, l’installation et l’administration de tels centres sont donc des tâches délicates. En particulier, chaque centre a ses propres spécificités de fonctionnement. Par exemple, certains centres sont dédiés à l’hébergement de services spécifiques (HPC, base de données etc.) et donc optimisés dans ce sens. D’autres centres au contraires sont conçus pour l’hébergement de services variés, et aux performances variables. De par cette variabilité des services, les activités d’un centre à l’autre sont différentes. De plus, dans un centre les activités des serveurs sont variables, que ce soit parmi différents serveurs du centre ou au cours du temps pour un serveur. Cette activité variable des serveurs est appelée charge de travail. Elle correspond à l’utilisation des ressources d’un serveur par rapport à ses capacités en ressources. Pour permettre une montée en charge des applications hébergées, l’administrateur veille à conserver une charge moyenne du centre faible. Même dans les centres de type HPC, où les services utilisent les serveurs au maximum de leurs capacités, des serveurs sont en attente de tâche à exécuter, donc sans activité. Les centres de données sont donc sur-dimensionnés en terme de capacité de calcul et d’infrastructure technique (dédié au refroidissement, au réseau, au stockage). Par soucis de rentabilité, des entreprises proposent de louer à des entreprises externes une partie des machines de leur centre (par exemple Amazon). Cette externalisation permet la mutualisation tant de la salle et du matériel que de la maintenance du centre, et donc du coût du centre. Suite à la croissance des besoins de tels centres, leur location est devenue une activité à part entière. Des entreprises se sont ainsi spécialisées dans l’hébergement de services informatiques. Pour l’entreprise cliente, délocaliser ses services réduit leur coût de maintenance et le besoin en personnel qualifié. Elle permet aussi d’améliorer la qualité des services, par exemple grâce à des infrastructures réseau ou de stockage dédiées, ou grâce à une expertise poussée.
Le cloud computing ajoute à cette notion de délocalisation des services une notion d’élasticité des ressources et de facturation à l’utilisation. Ces notions sont possibles grâce à la technique de virtualisation des ressources [AFG+10].
La virtualisation des systèmes informatiques
La technique de virtualisation des systèmes informatiques consiste à encapsuler l’environnement d’exécution d’un service dans un système virtuel(VM. Cette VM est ellemême exécutée sur un serveur grâce à un environnement logiciel spécifique appelé hyperviseur. Il est ainsi possible d’exécuter sur un même serveur plusieurs VM sans que celles-ci aient “conscience” les unes des autres. Cette technique permet d’améliorer le partage des ressources dans les centres. En effet, dans les centres non virtualisés chaque serveur participe à l’exécution d’un seul service. Chaque serveur nécessite donc l’installation des programmes spécifiques à ce service. L’administrateur du centre doit réagir quand l’exécution d’un service sur un serveur lui demande trop de ressources de calcul. Il peut alors soit re localiser les programmes sur un serveur plus puissant, soit répartir la charge des services sur un nombre plus important de serveurs. Dans les deux cas il doit disposer de nouveaux serveurs, les démarrer et leur installer les couches logicielles nécessaires. Il doit finalement paramétrer le centre pour prendre en compte cet accroissement des capacités de calcul. Cet accroissement des ressources mises à la disposition d’un service est très long à réaliser et donc peu pratique dans un centre de grande taille. Lorsqu’au contraire le besoin de calcul d’un service diminue, les serveurs exécutant ce service réduisent leurs activités. Certains serveurs peuvent alors être éteints pour réduire la consommation du centre ou être utilisés pour l’exécution d’autres services. Cependant, au vu de la difficulté à configurer les serveurs et du temps nécessaire pour les redémarrer, il n’est pas toujours possible d’éteindre ou de réaffecter des serveurs. C’est pourquoi, dans les centres non virtualisés, la reconfiguration logicielle d’un serveur est une tâche exceptionnelle.
Des technologies de cohabitation des services permettent d’exécuter sur un même serveur différentes configurations d’un même programme. Ce serveur peut ainsi héberger différentes configurations d’un même service, mais ces technologies apportent leurs propres inconvénients. Ainsi en cas de problème logiciel ou d’intrusion sur le serveur, ce sont les services de tous les clients qui sont menacés. De plus, la présence de plusieurs services sur un même serveur peut nécessiter le maintien de plusieurs couches logicielles. Cette cohabitation des services peut donc entraîner une complexité d’administration importante, pour des risques non négligeables.
Isolation et configuration
La virtualisation des services sépare les différents environnements logiciels de manière transparente. Ainsi, une VM atteinte par un virus ne contaminera pas les VM co-hébergées. La virtualisation apporte ainsi une solution efficace à la mutualisation des ressources informatiques pour l’hébergement de plusieurs services [FDF03]. Cependant, la présence d’un hyperviseur nécessite parfois une adaptation du système exécuté. Idéalement, les services exécutés sur un système virtualisé doivent être les même que sur un système non virtualisé. Ceci permet d’assurer les mêmes fonctionnalités sans nécessiter de développement spécifique. Pour cela, l’hyperviseur simule un environnement matériel connu de la VM. Ceci est possible par la virtualisation dite matérielle. Dans cette approche, l’exécution et le contrôle des ressources d’une VM sont proposés par des circuits spécifiques du serveur, sur le CPU par exemple [WRF+10]. La virtualisation est actuellement intégrée aux CPU, permettant à l’hyperviseur de contrôler les droits d’exécution de code des VM. Cette technique permet l’exécution de logiciels sans connaissance de la virtualisation. Elle peut cependant être améliorée par l’ajout de code spécifique dans les VM, par exemple des drivers virtualisés ou le remplacement dynamique de parties du code système. Ces modifications de la VM peuvent être effectuées si l’OS de la VM est conscient de la virtualisation, donc configuré pour celle-ci. Les programmes métiers de la VM restent cependant les mêmes que sur un serveur classique.
Dans certains l’OS est connu mais il est impossible d’installer un code dans la VM, par contrainte de sécurité par exemple. L’hyperviseur peut néanmoins insérer dynamiquement un code dans la mémoire de la VM sans que les changements soient visibles de l’intérieur de celle-ci. Ce tissage de code se limitant aux VM pour lesquelles l’OS est connu, il ne peut être effectué sur des VM génériques. Il permet cependant d’améliorer les performances du centre sans nécessiter de configuration des VM lorsque les conditions s’y prêtent.
|
Table des matières
Introduction
1 Présentation de la thèse
1.1 Les centres de données physiques et virtuels
1.2 Une consommation électrique toujours grandissante
1.3 Une solution flexible, efficace et agnostique pour la maîtrise énergétique des centres de données
1.4 Diffusion scientifique
I Contexte
2 Gestion énergétique de l’informatique dans les nuages
2.1 L’informatique dans les nuages
2.1.1 La virtualisation des systèmes informatiques
2.1.2 De la virtualisation aux XaaS
2.1.3 Cloud Computing
2.2 Maîtrise énergétique
2.2.1 Le calcul et l’énergie
2.2.2 Terminologie
2.2.3 Mesure énergétique dans un centre virtualisé
2.2.4 Leviers logiciels
2.2.5 Gestion de l’énergie dans les systèmes virtualisés
2.3 Conclusion
3 Entropy : une première solution
3.1 Programmation par contraintes
3.1.1 Modélisation à base de contraintes
3.1.2 Objectifs de résolution
3.1.3 Exploration d’un arbre des solutions
3.1.4 Cohérence des nœuds intermédiaires
3.1.5 Filtrage des contraintes
3.1.6 Optimisation et contraintes
3.1.7 Stratégie de recherche
3.1.8 Les solveurs de contraintes
3.2 Entropy
3.2.1 Boucle autonomique
3.2.2 d’Entropy à OPTIPLACE
3.3 Limites d’Entropy 2.0
3.3.1 Approche tout en un
3.3.2 Approche non flexible
3.4 Conclusion
II Contribution
4 OptiPlace
4.1 d’Entropy 2.0 à BTRCLOUD
4.1.1 Présentation de BTRCLOUD
4.2 OPTIPLACE
4.2.1 Programmation modulaire : les vues
4.2.2 Vers un système réflexif
4.3 La vue énergétique
4.3.1 Les données du problème
4.3.2 Modèles de consommation des serveurs
4.3.3 Gestion d’un centre sous contrainte énergétique
4.3.4 Conclusion et ouverture
4.4 La recherche de solutions
4.4.1 Différents types d’heuristiques
4.4.2 Approches mono-ressource
4.4.3 Approche multi-ressources
4.5 Conclusion
5 StressCloud
5.1 Problématique
5.2 Travaux apparentés
5.3 STRESSCLOUD : un cadriciel pour l’évaluation des gestionnaires de Clouds
5.3.1 Définitions et architecture
5.3.2 Génération des activités
5.3.3 Un langage dédié pour le contrôle des activités
5.4 Évaluation
5.4.1 Évaluation des stresseurs
5.4.2 Modélisation du coût électrique
5.4.3 Évaluation du langage
5.5 Conclusion
6 Expérimentation
6.1 OPTIPLACE et ENTROPY
6.1.1 Gestion des actions administrateur
6.1.2 Évolution du modèle de ressources
6.1.3 Passage à l’échelle pour des problèmes de grande taille
6.2 L’intégration de nouvelles contraintes et paramètres
6.2.1 Modèles de SLA de l’Impact Lab
6.2.2 Vue de regroupement
6.2.3 Gestion des priorité CPU
6.2.4 Activité et extinction des serveurs
6.3 Résolution de problèmes énergétiques
6.3.1 Évaluation de la recherche de la première solution
6.3.2 Consommation linéaire et nombre de ressources considérées
6.3.3 Modèle énergétique avec contraintes de placement
6.4 Conclusion
III Conclusion