Le concept de virtualisation

Comme le définit N. Triki (Triki 2013), « la virtualisation est un procédé informatique qui consiste à ajouter une couche d’abstraction entre les ressources physiques et la représentation logique d’un système ou d’un réseau informatique ». Afin de mieux comprendre ce concept, nous analysons les quatre principales manières de virtualiser un système.

La virtualisation complète 

La virtualisation complète permet de lancer une ou plusieurs machines virtuelles sur une machine physique munie d’un système d’exploitation. Chaque machine virtuelle sera munie de son propre système d’exploitation et fonctionnera sur la machine réelle comme un simple logiciel. on a alors plusieurs systèmes d’exploitation invités qui s’exécutent en parallèle sur un système hôte et tous sont hébergés sur la même  machine physique. Les différents systèmes invités n’ont pas conscience de partager la machine et ont l’impression de gérer toutes les ressources matérielles. Comme l’explique L. Bonnet dans son état de l’art (Bonnet-Bearstech), ce type de virtualisation nécessite que le système hôte récupère au vol toutes les instructions lancées par un système invité afin de réellement les exécuter. Cette opération est coûteuse en temps et est complexe, car, la plupart du temps, les instructions ne peuvent pas être simplement transmises au matériel et doivent être interprétées. D’après D.A. Menascé (Menascé 2005), les performances du système sont donc réduites par l’empilement des différentes couches d’abstraction entre le système invité et le matériel.

La paravirtualisation 

La paravirtualisation, en comparaison à la virtualisation complète, vise à diminuer le nombre de couches d’abstraction. Comme décrit par R. Gadhgadhi (Gadhgadhi 2013), on émule dans ce cas encore un système d’exploitation sur un autre grâce à une machine virtuelle, mais cette fois-ci, le système invité est conscient de ne pas gérer directement les ressources matérielles. Ce dernier a donc subi quelques modifications afin de collaborer avec le système hôte pour être plus performant, les instructions envoyées prennent  donc en compte le fait qu’elles vont devoir être interprétées par le système qui les exécutera. L’inconvénient de cette solution est que pour modifier un système d’exploitation il faut avoir accès au code source et la permission du détenteur des droits de le modifier. Il est donc possible de modifier un système libre tel que GNU/Linux et les systèmes BSD (Berkeley Software Distribution, licence libre utilisée pour la distribution de logiciels) mais pas les systèmes propriétaires comme Microsoft Windows et Mac OS. De plus, comme l’explique L. Bonnet (Bonnet-Bearstech), ce système n’est pas encore vraiment optimal, car il y a encore de nombreuses couches d’abstraction entre le système invité et le matériel.

Un système hyperviseur

Le système hyperviseur, pensé par Popek et Goldberg dans les années 70 (Popek and Goldberg 1974), a pour but de réduire encore le nombre de couches d’abstraction entre le système invité et le matériel. L’idée est donc de laisser aux systèmes invités un accès, bien que contrôlé, au matériel. Le système hyperviseur a donc été développé pour être un système d’exploitation minimaliste qui sert à allumer la machine puis à lancer les différents systèmes invités qui devront ensuite passer par lui pour soumettre leurs instructions au matériel. L’hyperviseur s’assurera juste que le système invité a les droits pour exécuter ce qu’il souhaite exécuter. Cette technique de virtualisation permet ainsi de meilleures performances que les deux méthodes précédemment présentées. En effet, comme l’expliquent R. Sailer et al. dans (Sailer, Valdez, et al. 2005) et (Sailer, Jaeger, et al. 2005), avec un système hyperviseur, le système invité n’est pas vu comme un processus par le système hôte. L’hyperviseur régule l’accès des systèmes invités aux ressources matérielles, il n’y accède pas pour eux. Les systèmes invités peuvent alors exploiter toutes les performances de la machine hôte et de ses périphériques. Cette technique nécessite donc un contrôle de l’accès au matériel et de l’utilisation des ressources plus fins mais permet un gain significatif des performances. De plus, ce système de virtualisation ne veille plus à ce qu’un système invité n’en dérange pas un autre, comme dans les solutions décrites auparavant, la granularité est plus fine, il veille à ce qu’un programme utilisateur ne dérange pas les autres programmes du système. Mais cette solution, comme la précédente, nécessite que le système hôte soit modifié. En effet, il faut adapter ces couches bas niveau pour qu’elles communiquent avec l’hyperviseur. Ces modifications sont très lourdes et peuvent augmenter la complexité du code. De plus, il faut avoir accès au code source du système d’exploitation que l’on souhaite utiliser et cela est impossible avec tous les systèmes propriétaires. Comme l’explique L. Bonnet (Bonnet-Bearstech), cette méthode de virtualisation permet donc de meilleures performances que celles précédemment décrites, mais les modifications du système d’exploitation devant être réalisées pour cela sont complexes et même parfois impossibles dans le cas de système d’exploitation propriétaire.

L’isolation ou virtualisation du système d’exploitation

L’isolation est la dernière idée présentée ici et décrite par F. Santy (Santy 2013). Cette technique,cherche à éliminer la couche restante entre le système qui souhaite exécuter des instructions, et le matériel. Pour ce faire, on ne va plus créer des machines virtuelles sur une machine réelle pour avoir chaque processus qui s’exécute dans un environnement à part. On va plutôt isoler tous ces processus sur un même système. Dans ce cas, tous les processus doivent pouvoir s’exécuter sur le même système d’exploitation où ils seront isolés les uns des autres. Un environnement, duplication du système hôte, est créé  pour chacun d’eux avec pour ressource seulement ce dont le processus a besoin pour fonctionner. Par la suite, cet environnement est nommé isolateur. Les processus ne peuvent pas sortir de cet environnement, ils ont donc une vision très limitée de l’état de la machine sur laquelle ils s’exécutent et ne savent pas quels autres processus s’exécutent en même temps qu’eux. Cela permet d’assurer la sécurité du système et des autres processus. Cette solution donne les meilleures performances en termes de rapidité d’exécution et permet à l’administrateur du système de gérer comme il le souhaite les ressources attribuées à chaque processus de manière indépendante. L’inconvénient est que chaque système invité est du même type que le système hôte. On ne pourra plus utiliser les techniques de virtualisation pour faire fonctionner sur sa machine physique un autre système d’exploitation que celui déjà installé.

Quelle que soit la solution retenue et mise en place, on peut donc donner l’illusion d’avoir un système dédié à un service avec en réalité une seule machine physique.

Table des matières

INTRODUCTION
0.1 Problématique
0.2 Objectif de la recherche
0.3 Méthodologie de travail et contributions
0.4 Organisation du rapport
CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Le concept de virtualisation
1.1.1 La virtualisation complète
1.1.2 La paravirtualisation
1.1.3 Un système hyperviseur
1.1.4 L’isolation ou virtualisation du système d’exploitation
1.1.5 Avantages et inconvénients de la virtualisation
1.2 Le nuage informatique
1.2.1 Les cinq caractéristiques essentielles du nuage
1.2.2 Les quatre modèles de déploiement du nuage
1.2.3 Les trois couches de l’architecture du nuage
1.2.4 Un contrat entre les acteurs du nuage
1.3 L’architecture des réseaux de prochaine génération
1.3.1 Le modèle en couche de l’architecture IMS
1.3.2 La virtualisation d’un système IMS
1.3.3 Les caractéristiques d’un système IMS virtualisé
1.4 Analyse du trafic et des ressources physiques d’un système IMS
1.4.1 Télémétrer les ressources
1.4.2 Mesure de l’efficacité d’un système de communication
1.4.3 Prédiction de la charge de trafic
1.5 Les statistiques comme outil de prédiction
1.5.1 Les méthodes de régression linéaire et non-linéaire
1.5.2 Les méthodes de régression des machines à support de vecteur
1.6 Conclusion du chapitre
CHAPITRE 2 OUTIL DE GESTION DU SYSTÈME IMS
2.1 Motivations
2.2 MAPE-K : un modèle de conception de systèmes autogérés
2.3 Description de l’outil construit
2.3.1 Architecture du module de télémétrie des services
2.3.2 Architecture du module de surveillance des ressources
2.3.3 Architecture du module d’analyse et de prédiction
2.3.4 Architecture du module de déploiement
2.4 Conclusion du chapitre
CHAPITRE 3 ALGORITHME DE PRÉDICTION DU TRAFIC
3.1 Hypothèses
3.2 Analyse préliminaire du système IMS virtualisé
3.2.1 Choix des différentes métriques relevées
3.2.2 Analyse de l’utilisation de la mémoire
3.2.3 Analyse de l’utilisation de la bande passante
3.2.4 Analyse de la charge du CPU
3.2.5 Analyse du taux de sessions interrompues
3.3 Algorithmes de prédiction de la charge du CPU
3.3.1 Règles tirées de l’analyse préliminaire
3.3.2 Algorithme de décision par seuil non prédictif
3.3.3 Algorithme de décision par seuil prédictif
3.3.4 Algorithme de décision par seuil prédictif moins gourmand
3.3.5 Algorithmes de prédiction SVM
3.3.6 Traitement des données recueillies
3.4 Conclusion du chapitre
CHAPITRE 4 ANALYSE DES PERFORMANCES
4.1 Configuration de la plateforme de test
4.2 Description des jeux de test simulés
4.3 Analyse du choix des seuils pour la charge du CPU
4.4 Analyse des performances de l’algorithme par seuil prédictif
4.5 Analyse des performances des algorithmes de prédiction SVR et (D)LS-SVM
4.6 Conclusion du chapitre
CONCLUSION

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *