Des conteneurs à l’émulation : les différentes possibilités de virtualiser des services

Virtualisation classique, conteneurs ou environnement protégé ? Que choisir ? Tout dépend en fait de ce que vous souhaitez virtualiser : un serveur complet, un environnement système, ou l’application seule.

La virtualisation s’est rapidement imposée sur les serveurs. De fait, elle offre de multiples avantages : agrégation de plusieurs machines virtuelles (VM) sur un unique serveur physique ; capacité à migrer aisément une VM d’un serveur vers un autre ; étanchéité entre l’OS hôte et l’OS virtualisé, etc.

Il existe plusieurs façons de virtualiser des services. En s’attaquant au serveur lui-même, à l’environnement applicatif, voire uniquement à l’application, en fonction du niveau d’abstraction requis. Tour d’horizon des possibilités qui vous sont offertes.

Virtualisation du serveur : émulation pure

Honneur à la technique qui a fait connaitre la virtualisation : la virtualisation de serveurs via l’émulation. Avec cette technique, une machine est simulée de façon logicielle sur votre serveur. La séparation entre machine physique et machine virtuelle est maximale. Toutefois, l’ensemble se montrera d’une lenteur souvent rédhibitoire.

Il est donc important de bien faire attention à ce que la solution de virtualisation que vous avez choisie ne s’appuie pas sur de l’émulation pure.

Dans certains cas, il n’existe pourtant pas d’autre alternative. Un processeur x86, par exemple, ne pourra prendre en compte du code SPARC. Virtualiser un service SPARC d’ancienne génération sur un serveur x86 classique impose donc de passer par une émulation complète d’une machine SPARC.

Virtualisation du serveur : avec accélération matérielle

Dès 2005, Intel a proposé des processeurs capables de prendre en charge la virtualisation de façon matérielle. Une avancée importante, qui a permis à la virtualisation de gagner en popularité, au point de s’imposer maintenant sur tous les serveurs.

Le coût en temps processeur imposé par une machine virtuelle devient très faible lorsque la technologie Intel VT est exploitée. L’émulation logicielle revient en piste pour certaines fonctions annexes, comme les entrées/sorties ou les accès réseau. Mais, là encore, des technologies d’accélération matérielle sont proposées par Intel.

Tous les serveurs x86 vendus aujourd’hui, par exemple les ProLiant de HPE, sont équipés de processeurs proposant un support matériel de la virtualisation.

Virtualisation du serveur : avec paravirtualisation

La paravirtualisation est une autre technique permettant d’accélérer le fonctionnement d’une machine virtuelle. Ici, le système virtualisé à conscience de fonctionner sur une autre machine et propose des pilotes permettant de communiquer directement avec elle.

Longtemps, la paravirtualisation a permis de booster les systèmes fonctionnant en pure émulation. Elle apportera toutefois aussi un sérieux coup d’accélérateur aux environnements modernes. En association avec l’accélération matérielle de la virtualisation, la paravirtualisation fait des étincelles.

Le coût en ressources de la virtualisation d’un serveur en mode paravirtualisé sur un processeur récent est presque négligeable. C’est donc la voie à privilégier. L’option accélérée sans paravirtualisation sera une solution de repli pour des OS plus anciens. L’émulation pure reste pour sa part un passage obligé pour assurer la portabilité entre architectures processeur.

Virtualisation de l’environnement : les conteneurs

L’autre méthode de virtualisation des services, ce sont les zones et conteneurs. Chaque environnement virtuel s’appuie sur son propre jeu d’outils, de librairies et d’applications, mais utilise une instance du kernel principal de la machine physique. L’impact sur les performances processeur est ainsi réduit au maximum. Et ce même si ce dernier ne propose pas de technologies matérielles de prise en charge de la virtualisation.

Ce système a largement été employé par le passé, via diverses solutions, comme les zones, les conteneurs LXC ou OpenVZ de Linux, ou encore Jail sous FreeBSD. C’est toutefois Docker qui a popularisé cette technique. Il permet en effet de packager et déployer des environnements en conteneur simplement. Lesquels pourront par la suite fonctionner sous Linux ou Windows. En général au sein de conteneurs LXC ou Hyper-V.

Les conteneurs ne vont pas toutefois sans apporter quelques problèmes : attribution moins fine et stricte des ressources système ; étanchéité moins importante avec l’OS hôte ; lien fort avec le système hôte. Les deux premiers points sont en cours d’amélioration. Le dernier va rester : un environnement Linux en conteneur ne peut fonctionner que sous Linux. Idem avec un conteneur Windows. Si Docker est commun aux deux OS, les conteneurs ne peuvent migrer d’un environnement système vers un autre.

Virtualisation du service ou chroot

Pour aller un peu plus loin, vous pouvez vous pencher sur un intermédiaire : la virtualisation applicative. Elle permet de réutiliser kernel et outils de l’OS hôte, mais tout en packageant service et dépendances dans un ensemble dédié. Dans bien des cas, les développeurs lui préfèrent toutefois aujourd’hui les conteneurs, qui permettent eux aussi de packager applications et librairies dans un même ensemble. Avec un poids certes plus important en matière de stockage, mais sans impact insurmontable sur les performances processeur.

D’autres techniques sont proposées. chroot est une fonctionnalité accessible sur les serveurs fonctionnant sous Unix (ou un de ses clones), et ce depuis pratiquement les débuts de cette famille d’OS. Ici, seul le système de fichiers est protégé. Le service ne peut en effet sortir du dossier qui lui est attribué, qu’il prendra d’ailleurs pour la racine de son système de fichiers. Une technique très légère et plutôt efficace du point de vue de la sécurité, si l’OS et ses applications ne sont pas troués outre mesure, bien entendu.

Le chroot est l’apanage des environnements maitrisés, comme un serveur web. Imaginons un serveur web Apache mutualisé entre plusieurs utilisateurs. L’accès au dossier de chaque nom de domaine se fait en SFTP, via des sessions chrootées de SSH. Impossible pour les utilisateurs de voir les données des autres. Et l’impact sur les performances de la machine est littéralement nul.

Quel degré d’abstraction ?

Peut-on encore parler de virtualisation lorsqu’il est question de chroot, ou d’une émulation 100 % logicielle ? Dans l’absolu non. Il serait en fait plus exact de parler d’un degré d’abstraction croissant appliqué aux services.

L’émulation est la solution d’abstraction ultime. Mais aussi la plus lente. Avec le support de la virtualisation hardware, puis de la paravirtualisation, il est possible d’accéder directement aux ressources processeur et aux entrées/sorties. Les conteneurs vont un cran plus loin, les services utilisant alors le kernel de l’OS principal. Avec la virtualisation des applications, seules l’application et ses dépendances sont séparées de l’OS. Enfin, chroot ne permet que de redéfinir la partie du système de fichiers visible par le service.