Performance et gestion de ressources dans un cloud multi-virtualisé

Cloud privé

Une plate-forme de cloud privé est mise en place uniquement pour un seul client. Le fournisseur de cloud peut être celui qui fournit la solution logicielle pour convertir le centre d’hébergement interne existant en plateforme cloud (et peut être l’utilisateur de la plate-forme lui-même) ; ou alors c’est lui qui héberge la plate-forme en donnant l’exclusivité à son client. L’intérêt est ici l’aspect organisationnel de la mutualisation plus que l’aspect financier, puisque l’utilisateur possède le centre d’hébergement cloud, ou achète une solution personnalisée. Le caractère privé aide à la sécurité des traitements et des données. L’exemple 2 décrit un cloud privé. 1 Des exemples de l’industrie sont le cloud privé d’Intel [25], ou les solutions de cloud privé OpenNebula [100].

Infrastructure-as-a-Service (IaaS)

Le niveau le plus bas consiste à louer l’infrastructure, c’est-à-dire un accès quasi-direct au serveur. Concrètement, l’utilisateur se voit attribuer une portion de ressource du centre d’hébergement cloud sous une forme telle qu’il semble avoir la possession d’un véritable serveur. Ainsi, il se trouve responsable du déploiement et de la maintenance de l’environnement qu’il va utiliser (installation d’un système d’exploitation par exemple). Ce niveau de contrôle le plus grand apporte donc une plus grande charge à l’utilisateur, ce qui diminue l’intérêt du cloud. Il reste néanmoins désirable pour simplement externaliser le centre d’hébergement. L’exemple 2 ne décrit pas un cloud IaaS ; ce pourrait être le cas si les ingénieurs n’avaient accès qu’à la ressource informatique brute et devaient gérer eux-mêmes leur environnement de simulation. Des exemples dans l’industrie de l’offre IaaS sont les services Amazon Elastic Compute Cloud [7], ceux du Google Compute Engine [29] ou encore IBM Cloud Virtual Servers [56].

Ordonnancement

Le partage des ressources du cloud entre tous ses utilisateurs nécessite un arbitrage : comment servir les requêtes en ressource de tous les utilisateurs ? Cette tâche est l’ordonnancement (en anglais scheduling), qui est accomplie par un ordonnanceur (scheduler). Elle consiste à décider quel serveur du centre d’hébergement cloud va fournir les ressources pour une requête (par exemple à la création d’une nouvelle entité fonctionnelle d’une application, demandée par la mise à l’échelle horizontale, voir section 2.1.4). C’est-à-dire que le rôle de l’ordonnanceur est d’attribuer des ressources physiques, aux ressources logiques vendues par la plate-forme cloud. Un but de l’ordonnancement est de servir toutes les requêtes, en allouant intelligemment les ressources de chaque serveur pour éviter le gaspillage ; il en va de l’efficacité de la mutualisation permise par le cloud. Mais l’ordonnancement est un problème difficile qui inclut notamment des notions d’équité et de latence de service dès lors que les profils de requêtes des utilisateurs se complexifient. De plus, il doit prendre en compte d’autres contraintes que la quantité de ressources disponibles : par exemple, certaines catégories de charges de travail ne devraient pas être placées sur le même serveur physique au risque de dégrader les performances. L’objectif d’allocation intelligente est facilité par le partage de la ressource informatique en ressources logiques (voir section 2.1.4) pour :
— allouer plus finement, en estimant le besoin réel de l’utilisateur pendant l’exécution de son application ;
— sur-allouer les ressources des serveurs, en supposant que les utilisateurs demandent en réalité plus de ressource qu’ils n’en ont besoin afin de soutenir des pics de charge.

Virtualisation du système d’exploitation

Contrairement à la virtualisation du matériel qui virtualise une machine entière, la virtualisation du système d’exploitation virtualise un environnement d’exécution pour une application, comme illustré en figure 2.8. Il s’agit de présenter à l’application un environnement d’exécution spécialement préparé et dédié à celle-ci, mais cloisonné du reste du SE hôte. Bien que d’autres termes existent en fonction de l’écosystème, on désigne ici cet environnement virtualisé comme un conteneur. Un conteneur consiste en un processus du SE, mais qui est particulier en ce qu’il n’a pas accès à toutes ses ressources. Par exemple, il ne peut voir qu’une arborescence limitée du système de fichiers, ou ne peut pas utiliser toutes les interfaces réseau ; ou encore, sa capacité d’allocation mémoire ou son débit d’entrée-sortie disque sont limités. Ces contraintes apposées sur le conteneur sont en fait des fonctionnalités du SE hôte, mais qui sont intégrées en une solution cohérente appelée moteur de conteneurs. Elles varient donc en fonction de la solution et du SE hôte. On distingue cependant deux catégories de ces contraintes : isolation cacher au conteneur des ressources ou composants du système (utilisateurs, sections du système de fichiers, interfaces réseau…) ; limitation contrôler l’accès aux ressources (limite d’allocation mémoire, de débit entrée-sortie réseau, d’utilisation du processeur…).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

1. Introduction
2. Contexte et problématiques
2.1. Le cloud
2.1.1. Présentation
2.1.2. Modèle de déploiement
2.1.3. Type de service
2.1.4. Technologies
2.2. La virtualisation
2.2.1. Présentation
2.2.2. Mode de virtualisation
2.2.3. Comparaison des modes de virtualisation
2.2.4. Applications de la virtualisation
2.3. Problématiques
2.3.1. Gestion des ressources virtualisées
2.3.2. Performance et prédictibilité
2.3.3. Problématiques dans le cloud doublement virtualisé
2.3.4. Contributions
3. La consolidation de la charge de travail : Drowsy-DC
3.1. Introduction
3.1.1. Efficacité énergétique
3.1.2. Limites de la consolidation
3.1.3. Problème de la mémoire virtualisée
3.1.4. Nouvelle vision de la consolidation
3.2. Notions préliminaires
3.2.1. Caractérisation des VM : SLMU, LLMU, LLMI
3.2.2. États énergétiques
3.3. Vue d’ensemble
3.4. Consolidation en fonction de l’inactivité
3.4.1. Principe
3.4.2. Construction du modèle d’inactivité (MI)
3.4.3. Calcul de la probabilité d’inactivité (PI)
3.4.4. Intégration dans OpenStack
3.4.5. Synthèse
3.5. Mise à jour du modèle d’inactivité
3.5.1. Calcul des scores SIX
3.5.2. Calcul des poids wX
3.6. Suspension des serveurs
3.6.1. Détection de l’inactivité
3.6.2. Délai de sursis
3.7. Reprise des serveurs
3.7.1. Reprise sur requête entrante
3.7.2. Reprise planifiée
3.7.3. Reprise de serveurs doublement virtualisés
3.8. Optimisation de la reprise des serveurs
3.8.1. Reprise du noyau
3.8.2. Reprise de la carte réseau
3.9. Évaluation
3.9.1. Évaluation en environnement réel
3.9.2. Évaluation par simulation
3.10. État de l’art
3.10.1. États de faible énergie
3.10.2. Consolidation de la charge de travail
3.11. Conclusion
4. L’auto-configuration des applications conteneurisées
4.1. Introduction
4.2. Allocation du processeur aux conteneurs
4.2.1. Allocation par le moteur de conteneurs
4.2.2. Allocation par l’orchestrateur
4.3. Analyse : violation du principe tel-tel et solutions
4.3.1. Installation
4.3.2. Méthodologie
4.3.3. Résultats
4.3.4. Synthèse
4.4. Algorithme d’allocation hybride de la ressource processeur
4.4.1. Conception
4.4.2. Algorithme
4.4.3. Détermination de la catégorie de conteneur
4.4.4. Intégration à Kubernetes
4.4.5. Limites de l’algorithme et pistes d’amélioration
4.5. Évaluation
4.5.1. Méthodologie
4.5.2. Résultats
4.6. État de l’art
4.6.1. Performance des conteneurs
4.6.2. Violation du principe tel-tel
4.6.3. Gestion de la ressource processeur virtualisée
4.7. Conclusion
5. La double virtualisation du réseau : BrFusion et HostLo
5.1. Introduction
5.2. Notions préliminaires
5.2.1. Pods
5.2.2. Virtualisation imbriquée du réseau
5.3. Analyse des défauts de la virtualisation réseau imbriquée
5.3.1. Origine
5.3.2. Déploiement mono-VM de pods
5.3.3. Duplication du réseau virtualisé
5.4. HostLo : déploiement inter-VM de pods
5.4.1. Vue d’ensemble
5.4.2. Intégration
5.4.3. Implémentation
5.4.4. Mise à jour de l’algorithme de placement des pods
5.4.5. Gestion des autres ressources
5.4.6. Évaluation
5.5. BrFusion : déduplication de la virtualisation du réseau
5.5.1. Vue d’ensemble
5.5.2. Intégration
5.5.3. Implémentation
5.5.4. Évaluation
5.6. État de l’art
5.6.1. Réseautage entre les VM
5.6.2. Réseautage dans les environnements virtualisés
5.7. Conclusion
6. Conclusion et perspectives
6.1. Multi-virtualisation du cloud
6.2. Pistes d’amélioration des travaux
6.3. Vers le cloud Function-as-a-Service multi-virtualisé