Architecture des hyperviseurs

De testwiki
Version datée du 23 avril 2023 à 18:22 par imported>WikiCleanerBot (v2.05 - Correction syntaxique (Orthographe et typographie - Paramètre inutilisé - DOI incorrect))
(diff) ← Version précédente | Version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche

Modèle:Article général L'architecture d'un hyperviseur englobe l'ensemble des composants et leur organisation qui permettent la mise en place de la virtualisation d'un ou plusieurs systèmes d'exploitations ou logiciels. En effet, le rôle d'un hyperviseur, qu'il soit de type 1 (natif) ou de type 2 (invité) est de fournir pour chaque machine virtuelle un ensemble de modules et d'interfaces qui est une virtualisation d'un environnement physique réel. À travers ces modules, nous trouverons une abstraction de la mémoire physique, un système d'ordonnancement entre machine virtuelle, ainsi que d'autres périphériques physiques tels que des cartes réseaux virtuelles.

La mise en place d'une infrastructure virtualisée grâce à un hyperviseur implique un ensemble de contraintes liés à l'allocation de ressources aux machines virtuelles, celle-ci pouvant être plus ou moins gourmande.

Catégories d'hyperviseur

Catégories des hyperviseurs
Catégories des hyperviseurs

Architecture native

Les hyperviseurs natifs (type 1) sont directement intégrés au système d'exploitation de la machine hôte[1].

Dans cette approche, l'hyperviseur communique directement avec le matériel sur lequel il est exécuté. Il est également en mesure d'intercepter les entrées/sorties et d'en abstraire l'exécution pour le système d'exploitation invité[2].

Une architecture native fournit une virtualisation du matériel aux machines virtuelles. En effet, ces dernières interagissent avec des périphériques virtuels via des pilotes fournis par l'hyperviseur[2].

Architecture invitée

Les hyperviseurs invités (type 2) sont exécutés au sein même d'un autre système d'exploitation[2], de ce fait ils n'ont qu'un accès limité aux ressources de la machine hôte, il est donc possible d'exécuter plusieurs hyperviseurs de ce type sur une même machine[1].

L'hyperviseur fourni une virtualisation du matériel au système invité. Lors d'un appel à une instruction privilégiée, l'hyperviseur vérifie sa cohérence avant de l’exécuter[2].

Méthodes de virtualisation

Modèle:Article connexe

Virtualisation Complète

Dans le cas d'une virtualisation complète, le système invité ignore se trouver dans un environnement virtualisé. L'hyperviseur fournit une virtualisation de l'architecture et des ressources nécessaires à l’exécution du système invité, impliquant qu'il n'est pas nécessaire de modifier ce dernier[3].

Dans ce cas, les périphériques d'entrée/sortie utilisés par les machines virtuelles ne sont que des abstractions des périphériques physiques générées par l'hyperviseur. Toute interaction avec ces périphériques virtuels est redirigée directement vers les périphériques physiques[4]. De ce fait, ce type de virtualisation offre la meilleure solution en matière de performances, d'isolation et de sécurité des machines virtuelles. De plus, cette méthode simplifie la portabilité et la migrations de machines virtuelles[3].

Dans ce modèle, l'hyperviseur est exécuté avec un niveau de privilège 0 (ring 0). A contrario, les machines virtuelles sont exécutées avec un niveau de privilège 1 (ring 1). Ce niveau de droit permet d'assurer l'isolation des machines virtuelles en les empêchant d'exécuter directement des instructions sur le matériel, seules celles interceptées par l'hyperviseur pourront être exécutées[5].

Virtualisation Partielle

Dans un modèle de virtualisation partielle, le système invité doit être modifié afin de pouvoir fonctionner dans l'environnement virtuel. La machine virtuelle a donc conscience de se trouver dans un environnement virtualisé[3]Modèle:,[6].

Même si les machines virtuelles sont exécutées avec un niveau de privilège «Ring 1» (droits d'accès limités), celles-ci sont tout de même gérées par l'hyperviseur qui lui dispose du niveau de privilège «Ring 0» (droits maximum)[7].

Les machines virtuelles n'ont accès qu'à des ressources virtualisées (cartes réseaux, disques durs). Ces ressources sont fournies par l'hyperviseur, qui est chargé d'intercepter les instructions transmises par les systèmes invités, et de les rediriger vers les périphériques physiques correspondants[4]Modèle:,[2]. Dans cette situation, on dit que les systèmes invités utilisent des «Hypercalls», des demandes de ressources à l'hyperviseur[6].

Mécanismes de l'hyperviseur

Dans un système de machines virtuelles, les ressources (mémoire, processeur, périphériques) sont gérées par l'hyperviseur. Chaque ressource de chaque machine virtuelle est gérée via des algorithmes d'ordonnancement et de gestion fournis par l'hyperviseur[3].

Ordonnancement

La répartition du temps CPU est une problématique importante pour la virtualisation. En effet, l'hyperviseur se doit d'adopter une politique d'ordonnancement précise et équitable pour ses machines virtuelles. Pour ce faire, il utilise des algorithmes d'ordonnancement visant à accorder un accès équitable aux ressources[8].

Les algorithmes suivant sont utilisés par des solutions de virtualisation :

  • Temps virtuel partagé (Borrowed Virtual Time) : Algorithme d'ordonnancement équitable basé sur un temps virtuel, fournissant les ressources aux différentes machines virtuelles chacune à leur tour[9].
  • The Simple Earliest Deadline First : Algorithme en temps réel et préemptif. Chaque processus Domi indique à l'hyperviseur le temps d'utilisation du processeur dont il a besoin sous la forme (si,pi,xi) (avec si la taille de chaque tranche de temps de periode pi). Ainsi l'hyperviseur fourni au processus une fraction du temps d'utilisation du processeur demandé par chaque machine virtuelle[10]Modèle:,[11]. Cela permet une répartition plus équitable du temps processeur accordé à chaque machine puisque les machines qui en ont le plus besoin auront droit à plus de temps de calcul que les autres.
  • The Credit Scheduling algorithm : Algorithme d'ordonnancement et de répartition de charge proposé par Xen[3] : à chaque machine virtuelle se voit assigner un poids et une casquette. Si la casquette est égale à 0, la machine virtuelle peut recevoir du temps CPU supplémentaire. Une valeur non nulle de la casquette (exprimée comme un pourcentage) détermine la limite maximum de temps CPU que peut recevoir une machine virtuelle[12]Modèle:,[10].

Virtualisation des ressources mémoires

Translation d'adresse grâce aux shadow page table
Translation d'adresses grâce aux shadow page table

Dans le cadre de la virtualisation de la mémoire physique, deux espaces d'adressage sont gérées par l'architecture de l'hyperviseur :

  • Un espace d'adressage utilisé par l'hyperviseur, appelé «page table». Cet espace d'adressage est équivalent à celui présent sur un système d'exploitation standard[2]Modèle:,[6].
  • Un espace d'adressage utilisé par les machines virtuelle, appelé «shadow page table». Ce dernier est fourni par l'hyperviseur, qui se charge de traduire les adresses virtuelles du système invité vers les adresses virtuelles de sa «page table»[6]Modèle:,[2].

De plus, étant dans un environnement virtualisé, l'hyperviseur fourni aux machines virtuelles un ensemble de modules virtuels équivalent à ceux qu'on trouve dans une architecture physique. On trouve notamment une MMU (Memory Management Unit) et une TLB (Translation Lookaside Buffer) virtuelles et gérée par l'hyperviseur.

Déroulement d'une translation d'adresse[13]Modèle:,[2]Modèle:,[6] :

  1. Lorsque le système invité effectue une demande d'accès mémoire, ce dernier utilise les adresses virtuelles de la «shadow page table»
  2. La TLB virtuelle reçoit cette requête qui la transmet à la MMU virtuelle
  3. S'il existe une correspondance, l'adresse trouvée est transmise à la MMU de l'hyperviseur. Sinon, une exception « Page Fault » est déclenchée et redirigée vers la MMU de l'hyperviseur pour qu'il la traite
  4. La MMU de l'hyperviseur se charge de récupérer dans la «page table» l'adresse physique correspondante
  5. Si l'adresse physique existe, la translation est effectuée et l'adresse trouvée est retournée à la MMU de l'hyperviseur
  6. Enfin, la machine virtuelle récupère l'adresse physique correspondant à l'adresse virtuelle dans la shadow page table

Virtualisation des périphériques et des entrées/sortie

Il existe de nombreux outils permettant la gestion de périphériques entre plusieurs machines virtuelles. En effet, les interfaces réseaux virtuelles et les commutateurs permettent de créer des réseaux virtuels et d'y associer les machines virtuelles corréspondante[14].

De plus l'hyperviseur virtualise la couche matérielle et offre à chaque machine virtuelle un ensemble de périphériques virtuels standardisés afin de garantir la portabilité entre les architectures sur lesquelles l'hyperviseur serait exécuté[14].

Implémentations existantes

Xen

Logo Xen
Xen

Modèle:Article connexeXen est un hyperviseur natif très complet directement intégré au noyau linux de la machine hôte. Il offre à l'utilisateur le choix entre les 2 types de virtualisation et fournit ses propres mécanismes de gestion des ressources (ordonnanceur, gestionnaire de mémoire)[15]Modèle:,[16].

Les machines virtuelles créées sont isolées au sein d'un espace d'entrées/sorties dédié. Afin de gérer les ressources allouées aux machines virtuelles, Xen limite les accès privilégiés au matériel ainsi que les vecteurs d'interruptions. De plus, Xen virtualise la configuration matérielle pour que les machines invitées puissent consulter les ressources disponibles pour lui sans pour autant leur permettre d'accèder au reste des ressources matérielles[17].

Chaque page de la mémoire est détenue par au plus un domaine à la fois, et grâce à l'hyperviseur, il peut intéragir avec ces pages mémoires[18]Modèle:,[19]. De plus, l'ordonnancement des taches sous Xen s'effectue grâce à l'algorithme «The Credit Scheduling algorithm»[20]Modèle:,[21].

Il existe plusieurs versions du noyau linux intégrant Xen nativement. Néanmoins, du fait de sa complexité, son intégration à un noyau linux existant peut poser de nombreux problèmes[22]. Dans le cas d'une intégration d'hyperviseur à un noyau existant, il sera conseillé d'opter pour une solution plus simple d'installation.

KVM

Modèle:Article connexe

KVM (Kernel based Virtual Machine) est un hyperviseur natif de virtualisation complète. Il est très léger (environ Modèle:Nombre de codes) et est installé sous la forme d'un simple module linux ce qui le rend très simple d'installation et d'utilisation[15]Modèle:,[22].

KVM fait directement appel aux mécanismes de gestion des ressources intégrés au noyau linux et considère les machines virtuelles comme de simples processus[15]Modèle:,[22].

Du fait du jeune âge du projet, KVM ne peut pas virtualiser toutes les architectures et il peut être intéressant d'opter pour un hyperviseur plus complet comme Xen[15].

Références

Modèle:Références

Bibliographie

Liens externes

Modèle:Portail

  1. ↑ 1,0 et 1,1 Modèle:Harvsp
  2. ↑ 2,0 2,1 2,2 2,3 2,4 2,5 2,6 et 2,7 Modèle:Harvsp
  3. ↑ 3,0 3,1 3,2 3,3 et 3,4 Modèle:Harvsp
  4. ↑ 4,0 et 4,1 Modèle:Harvsp
  5. ↑ Modèle:Harvsp
  6. ↑ 6,0 6,1 6,2 6,3 et 6,4 Modèle:Harvsp
  7. ↑ Modèle:Harvsp
  8. ↑ Modèle:Harvsp
  9. ↑ Modèle:Harvsp
  10. ↑ 10,0 et 10,1 Modèle:Harvsp
  11. ↑ Modèle:Harvsp
  12. ↑ Modèle:Harvsp
  13. ↑ Modèle:Harvsp
  14. ↑ 14,0 et 14,1 Modèle:Harvsp
  15. ↑ 15,0 15,1 15,2 et 15,3 Modèle:Harvsp
  16. ↑ Modèle:Harvsp
  17. ↑ Modèle:Harvsp
  18. ↑ Modèle:Harvsp
  19. ↑ Modèle:Harvsp
  20. ↑ Modèle:Harvsp
  21. ↑ Modèle:Harvsp
  22. ↑ 22,0 22,1 et 22,2 Modèle:Harvsp
Récupérée de "https://fr.wiki.beta.math.wmflabs.org/w/index.php?title=Architecture_des_hyperviseurs&oldid=15767"