Partage des ressources en infonuagique

Architecture traditionnelle

Les plateformes traditionnelles hébergent les applications dans des serveurs physiques n’ayant aucune couche de virtualisation. En effet l’application s’exécute au niveau du système d’exploitation et utilise les ressources qui lui sont disponibles, par ailleurs, la majorité des serveurs d’un centre de données opèrent pour des applications liées à des domaines spécifiques. Ceci a principalement conduit à la non-élasticité et l’inefficacité de l’utilisation des ressources physiques. Mis à part les contraintes de sauvegarde qui imposent le déploiement d’un serveur entier ou plus pour cette affaire, ces plateformes ne sont pas en mesure d’exécuter des techniques efficaces destinées à la migration des applications et services. En conséquence, des troubles tels que le gaspillage de ressources et d’énergie s’affichent. Le problème de partage des ressources a longuement motivé les chercheurs à creuser plus pour révéler des techniques fiables améliorant d’une manière appropriée le partage de l’infrastructure physique, et ce, dans l’objectif de l’exploiter convenablement et satisfaire simultanément les services offerts. Architecture virtualisée Contrairement aux plateformes traditionnelles, cette architecture s’appuie sur la virtualisation pour achever un partage convenable du matériel sous-jacent. Il devient ainsi possible de fournir plusieurs services ayant des exigences matérielles et logicielles différentes depuis le même serveur tout en assurant une isolation propice et un partage juste.

Virtualisation des hôtes

La virtualisation consiste à abstraire un système d’exploitation invité du matériel sous-jacent (Daniels, 2009). Un composant appelé hyperviseur est responsable de l’émulation du matériel et constitue une couche intermédiaire se trouvant entre le système natif et invité. À l’exception de certains cas, le système invité n’a pas généralement conscience de la couche de virtualisation et opère comme un système natif. D’un autre côté, l’hyperviseur est un composant logiciel qui permet de créer et gérer des VMs. Il présente ainsi la couche de virtualisation responsable à l’émulation du matériel et essentielle au partage d’une même ressource. Il existe deux types d’hyperviseurs, le type 1 qui s’exécute directement sur l’infrastructure physique garantissant aux systèmes invités une performance semblable à celle d’un système natif (Guérineau, 2008). Le type 2 consiste à un composant logiciel s’installant et s’exécutant dans le système natif. Selon Hugo dans (Guérineau, 2008), les systèmes invités doivent passer par deux couches logicielles pour atteindre le matériel ce qui réduit la performance. Toutefois ce type d’hyperviseurs présente l’avantage d’une installation et configuration simple. Les hyperviseurs les plus connus dans l’industrie ainsi que la recherche sont QEMU/KVM (Kernel-based Virtual Machine), Xen, Hyper-V, VMware ESX.

Applications hébergées Contraintes par les limites des ressources physiques locales, de nombreuses applications sont hébergées dans l’infonuagique afin de répondre à leurs besoins. Quand nous évoquons le sujet de l’infrastructure physique et sa puissance de calcul, la performance des VMs et conséquemment celle des applications qui y résident est au rendez-vous. La solution vers l’amélioration de la performance consiste donc à migrer vers l’infonuagique, cela permettra également d’éviter le coût élevé du matériel. Il existe plusieurs types d’applications qui sont aujourd’hui accessibles depuis l’infonuagique, le commerce mobile en est un bon exemple, ce dernier doit faire face à de multiples défis essentiellement relatifs à la sécurité, la faible bande passante et la complexité élevée. Ces défis ont été adressés grâce à l’infonuagique (Dinh et al., 2013). D’une manière similaire, les applications déployées dans les environnements intelligents et ayant le concept d’apprentissage automatique sont exigeantes en terme de ressources de calculs et de stockages. Les applications servant le domaine médical et celles des jeux vidéo ont, de même, besoin de ressources puissantes. Il est important de mentionner que les applications hébergées dans le nuage informatique ont une consommation variable dans le temps, autrement, le nuage est la meilleure solution pour leur accorder plus ou moins de ressources dépendamment des besoins (Lorido-Botran, Miguel-Alonso et Lozano, 2014).

Table des matières

CHAPITRE 1 INTRODUCTION
1.1 Contexte
1.2 Problématique
1.3 Questions de recherche
1.4 Objectifs
1.5 Hypothèse
1.6 Plan du mémoire
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Plateforme physique
2.2.1 Architecture traditionnelle
2.2.2 Architecture virtualisée
2.2.2.1 Virtualisation des hôtes
2.2.2.2 Virtualisation des réseaux
2.3 Plateformes infonuagiques
2.3.1 Applications hébergées
2.3.2 Openstack
2.3.2.1 Services
2.3.2.2 Architecture
2.3.2.3 Migration des VMs
2.4 Partage des ressources en infonuagique
2.4.1 Relocalisation dynamique
2.4.2 Prédiction de la charge de travail
2.4.2.1 Les séries temporelles
2.4.2.2 Les modèles statistiques
2.4.2.3 Étapes de prédiction : cas d’ARIMA
2.5 Travaux connexes
2.5.1 Solutions basées sur la relocalisation
2.5.2 Solutions basées sur la prédiction
2.5.3 Limites
2.6 Conclusion
CHAPITRE 3 MÉTHODOLOGIE
3.1 Introduction
3.2 Modèle de prédiction
3.3 Modèle de partage des ressources physiques
3.3.1 Modèles d’estimation des coûts de relocalisation
3.3.1.1 Coût de migration
3.3.1.2 Coût d’hébergement
3.3.2 Formulation du problème
3.3.2.1 Modèle 1 : sans prédiction
3.3.2.2 Modèle 2 : avec prédiction
3.3.3 Algorithme
3.4 Système proposé
3.4.1 Hypothèses du système
3.4.2 Architecture du système
3.5 Conclusion
CHAPITRE 4 RÉSULTATS EXPÉRIMENTAUX
4.1 Introduction
4.2 Implémentation du système
4.2.1 Collecte des données
4.2.1.1 Agents de collecte des données
4.2.1.2 Agent réseau
4.2.1.3 Modules moniteurs
4.2.2 Modules de prédiction de l’utilisation des ressources physiques
4.2.2.1 Analyseur
4.2.2.2 Prédicteur
4.2.3 Modules de relocalisation
4.2.3.1 Module de prise de décision
4.2.3.2 Module de migration des VMs
4.3 Protocole expérimental
4.4 Environnement expérimental
4.4.1 Configuration physique
4.4.2 Déploiement d’Openstack
4.4.2.1 Approche multi-nœuds
4.4.2.2 Réseau virtuel d’Openstack
4.5 Description du scénario
4.6 Résultats et interprétation
4.6.1 Prédiction
4.6.1.1 Choix des paramètres
4.6.1.2 Future utilisation des ressources physiques
4.6.2 Minimisation du coût opérationnel
4.6.2.1 Comparaison entre les différents types de migration
4.6.2.2 Comparaison entre MIXT et les migrations individuelles
4.6.2.3 Modèle 1 vs Modèle 2
4.6.2.4 MIXT vs MM
4.7 Discussion
4.8 Conclusion
CONCLUSION
ANNEXE I PLANS DE RELOCALISATION
BIBLIOGRAPHI

Télécharger le rapport complet