Table des matières

1. Virtualisation et conteneurisation

La virtualisation est une technique qui existe depuis les années 60, mais elle n’a été généralisée que dans les années 2000, suite à l’évolution des ressources hardware disponibles et des besoins des utilisateurs. 

1.1. Motivation

A quels besoins répond la virtualisation?  

Besoins auxquels la virtualisation répond

  • Gestion efficace des ressources hardware : Auparavant, il était considéré comme une bonne pratique de dédier des serveurs à des tâches spécifiques : Le serveur web s’occupe du service web, le server mail du service mail, etc. Cela permettait de bien séparer les tâches, d’éviter les conflits entre les services, et d’adapter le hardware à un besoin unique spécifique. Avec l’évolution des performances du matériel et avec les pratiques d’over-provisionning (prévoir de la marge au niveau des performances du matériel pour les besoins futurs), les services n’utilisaient finalement en pratique qu’une petite partie du matériel 
  • Isolation : déployer les services sur des machines séparées permet de les isoler les uns des autres et d’éviter qu’une faiblesse de l’un impacte l’autre, de part le partage des ressources.  
  • Migration : Migrer un service ou une application sur un hardware différent peut être hasardeux, voire impossible lorsque des technologies propriétaires sont en jeu.   
  • Partage de machines entre différents utilisateurs
  • Accès facilité à des systèmes d’exploitation multiples, par exemple pour avoir accès à une application non disponible sur le système natif.  
  • Environnements multiples (développement, tests, sandbox, …) : Disposer d’un environnement isolé permettant de tester des applications ou des manipulations hasardeuses et potentiellement risquées, sans mettre en danger le système principal. 

A lire  : Red Hat, _petite histoire de la virtualisation

1.2. Qu’est ce que la virtualisation? 

schéma virtualisation

Virtualiser consiste à donner l’illusion à un OS qu’il est seul à avoir le contrôle de la machine sur laquelle il tourne, alors qu’en pratique, plusieurs OS sont exécutés sur cette même machine.  

La couche logicielle qui permet cette séparation HW/OS s’appelle le “gestionnaire de machines virtuelles” (Virtual Machine Monitor), ou, plus couramment, hyperviseur.  L’hyperviseur doit donner l’illusion aux systèmes d’exploitation virtualisés qu’ils tournent directement sur le hardware.  

Wikipédia définit un hyperviseur comme suit : “En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une même machine physique en même temps.”

On peut faire une analogie entre les systèmes d’exploitation et les hyperviseurs : 

  • Un système d’exploitation permet à des applications/processus de tourner sur une machine en étant isolés les uns des autres (partage de CPU, système de mémoire virtuelle, …) 

  • Un hyperviseur permet à des systèmes d’exploitation de tourner sur une machine en étant isolés les uns des autres (partage de CPU, de la mémoire, des périphériques)

Les challenges de l’hyperviseur sont, entre autres, liés au fait qu’un OS s’attend à pouvoir exécuter les instructions CPU en mode privilégié alors qu’en pratique, il ne dispose pas de ces privilèges.  L’hyperviseur doit donc intercepter ces instructions (“Trap and Emulate”) et faire en sorte qu’elles s’exécutent de manière adéquate.

1.3. Spécifications de Popek et Goldberg [facultatif]

Spécifications de Popek et Goldberg

En 1974, deux chercheurs, G. Popek et R. Goldberg, ont proposé un ensemble de conditions suffisantes* pour permettre à une architecture informatique de supporter efficacement la virtualisation.  Les trois propriétés à respecter par l’hyperviseur sont : 

  • L’équivalence : Un programme s’exécutant de manière virtuelle doit avoir le même comportement que s’il s’exécutait directement sur le matériel
  • Le contrôle des ressources : L’hyperviseur doit avoir le contrôle complet des ressources virtualisées
  • L’efficacité : Une portion importante des instructions machine doit être exécutée directement par le CPU, sans intervention de l’hyperviseur.  La majorité du temps, l’OS virtualisé exécute donc bien les instructions CPU directement sur celui-ci, contrairement à ce qui se passe lors de l’émulation (cfr plus loin). 

* Popek, G. J.; Goldberg, R. P. (July 1974). “Formal requirements for virtualizable third generation architectures”. Communications of the ACM17 (7): 412–421

En pratique, ces conditions n’ont par exemple pas été remplies par les architectures Intel x86 avant les années 2000, notamment parce que certaines instructions de l’OS, exécutées en mode non privilégiée, ne déclenchaient pas le “TRAP” (=exception/interruption système déclenchée lors d’une exécution d’instruction non autorisée sur le CPU) permettant l’intervention de l’hyperviseur.   La virtualisation a été rendue possible sur cette plateforme par la société VMWare, qui a proposé un mécanisme alternatif : la “binary translation”, qui consiste à traduire les instructions de l’OS invité avant leur exécution, sans devoir utiliser le mécanisme de “TRAP”.

1.4. Les différents types de virtualisation

Il existe différents types de virtualisation, dépendamment des usages et des techniques utilisées. 

1.4.1. Hyperviseur de type I ou de type II

Hyperviseur de type I.

Un hyperviseur de type I, ou hyperviseur natif, ou encore bare metal, est un logiciel qui tourne directement sur le hardware et permet de faire tourner différents systèmes d’exploitation sur le matériel cible.  Ce type d’hyperviseur va typiquement être utilisé sur des serveurs qui serviront à héberger des infrastructures virtualisées (ex : datacenter). ESXi et Proxmox sont deux exemples d’hyperviseurs de type I. 

Hyperviseur de type II.

Un hyperviseur de type II tourne, quant à lui, au dessus d’un système d’exploitation “hôte”, et permet à l’utilisateur d’utiliser des machines virtuelles en plus de son système principal.  C’est ce type de virtualisation qui permet aux particuliers de faire tourner des OS virtualisés sur leurs machines personnelles.  VMWare Workstation, Player, Fusion, ou bien VirtualBox sont des hyperviseurs de type II.  

1.4.2. Virtualisation complète, assistée par le matériel et paravirtualisation

La virtualisation complète est la technique qui permet de virtualiser des systèmes d’exploitation “classiques”, sans les informer ou devoir les modifier du fait qu’ils sont virtualisés.  Cette technique est plus facile à mettre en oeuvre (pas de modification de l’OS invité), mais aura des performances moindres car l’hyperviseur ne peut pas compter sur la “collaboration” de l’OS invité.  

La virtualisation assistée par le matériel est une technique rendue possible par les évolutions récentes des plateformes matérielles, qui intègrent des mécanismes facilitant la virtualisation.   Ces mécanismes sont par exemple Intel-VT et AMD-V.  Ils consistent par exemple à fournir un niveau de privilèges supplémentaires permettant l’exécution de l’hyperviseur “en dessous” de l’OS invité tout en laissant ce dernier au niveau privilégié classique, ou à fournir des instructions CPU liées à la gestion de la virtualisation, ou encore à proposer un niveau supplémentaire à la table des pages pour la gestion de la mémoire des systèmes virtualisés.  

La paravirtualisation consiste quant à elle à obtenir la collaboration de l’OS virtualisé en le modifiant de telle sorte qu’il coopère avec l’hyperviseur.  L’OS invité doit donc tourner dans une version adaptée à cet usage.  

1.4.3. Emulation

La virtualisation permet l’exécution de plusieurs OS sur une même architecture matérielle.  Par contre, elle ne permet pas de faire tourner un système sur un hardware pour lequel il n’est pas conçu.  En effet, la majorité des instructions du système virtualisé sont exécutées directement sur le CPU : elles doivent donc être compatibles avec ce dernier! 

Lorsqu’on souhaite exécuter un système sur un hardware avec lequel il n’est pas compatible, il faut alors traduire chaque instruction vers une instruction correspondante sur le CPU hôte.   Ce mécanisme s’appelle l’émulation.   Bien qu’il puisse répondre à des besoins fonctionnels spécifiques,  il nécessite des ressources de calcul importantes pour assurer la traduction de l’ensemble des instructions.  QEmu, Bochs, ou encore CrossOver sont des exemples d’émulateurs.  

1.4.4. Conteneurisation

Diagramme ArchiIsolateur

Conteneurisation. Figure par Primalmotion, CC BY-SA 3.0, via Wikimedia Commons

La virtualisation est un mécanisme puissant répondant aux besoins identifiés plus haut.  Néanmoins, pour virtualiser une application données, il faut virtualiser un OS complet, avec la charge de calcul que cela représente.  

La conteneurisation est une alternative permettant l’isolation des applications sans devoir ajouter une couche de système d’exploitation supplémentaire, permettant un gain de performances important.  L’idée est de permettre aux applications conteneurisées d’utiliser le noyau du système d’exploitation hôte, en étant entièrement isolés du système hôte et des autres conteneurs (espace mémoire propre et ressources systèmes partagées de manière contrôlée).  

Docker et LXC (Linux Container) sont deux exemples de techniques de conteneurisation.  

Ressources