Virtualisation

La virtualisation des données est une approche permettant d'unifier les données de plusieurs sources dans une même couche afin que les applications, les outils de génération de rapports et les utilisateurs finaux puissent accéder aux données sans avoir besoin de détails sur la source, l'emplacement et les structures de données d'origine[2].

Il peut sembler a priori étrange de simuler d'autres machines sur une machine hôte : un système d'exploitation est conçu pour utiliser du matériel qui est entièrement sous son contrôle. La juxtaposition de plusieurs systèmes non conçus pour communiquer entre eux peut faire craindre des inefficiences auxquelles s'ajoute le fait que le processus de virtualisation consomme des ressources. Le tableau n'est pas aussi sombre. D'une part, on évite une grande partie de ces inefficiences juste en disposant de disques différents pour chaque système, et d'autre part le coût de la mémoire permet à chacun de ces systèmes de rester résident, et parfois avec de larges sections de code partagées[3]. Par ailleurs, le microcode des mainframes comme des microprocesseurs inclut de plus en plus de fonctionnalités qui rendent la virtualisation plus efficace[4].

Enfin, il est courant pour une entreprise de disposer d'une quinzaine de serveurs fonctionnant à 15 % de leur capacité, de façon à pouvoir faire face aux pointes de charge sporadiques. Un serveur chargé à 15 % consomme autant d'énergie qu'un serveur chargé à 90 %, et regrouper plusieurs serveurs sur une même machine s’avère rentable si leurs pointes de charge ne coïncident pas systématiquement, même en incluant la charge de la virtualisation[5]. La virtualisation des serveurs permet aussi une bien plus grande modularité dans la répartition des charges et la reconfiguration des serveurs en cas d'évolution ou de défaillance momentanée (plan de secours, etc.).

Chaque outil de virtualisation met en œuvre une ou plusieurs de ces notions :

• couche d'abstraction matérielle et/ou logicielle ;
• système d'exploitation hôte (installé directement sur le matériel) ;
• systèmes d'exploitation (ou applications, ou encore ensemble d'applications) « virtualisé(s) » ou « invité(s) » ;
• partitionnement, isolation et/ou partage des ressources physiques et/ou logicielles ;
• images manipulables : démarrage, arrêt, gel, clonage, sauvegarde et restauration, sauvegarde de contexte, migration d'une machine physique à une autre ;
• réseau virtuel : réseau purement logiciel, interne à la machine hôte, entre hôte et/ou invités.

Les intérêts sont :

• utilisation optimale des ressources d'un parc de machines (répartition des machines virtuelles sur les machines physiques en fonction des charges respectives) ;
• installation, déploiement et migration facile des machines virtuelles d'une machine physique à une autre, notamment dans le contexte d'une mise en production à partir d'un environnement de qualification ou de pré-production, livraison facilitée ;
• économie sur le matériel par mutualisation (consommation électrique, entretien physique, surveillance, support, compatibilité matérielle, etc.)
• installation, tests, développements, cassage et possibilité de recommencer sans casser le système d'exploitation hôte ;
• sécurisation et/ou isolation d'un réseau (cassage des systèmes d'exploitation virtuels, mais pas des systèmes d'exploitation hôtes qui sont invisibles pour l'attaquant, tests d'architectures applicatives et réseau) ;
• isolation des différents utilisateurs simultanés d'une même machine (utilisation de type site central) ;
• allocation dynamique de la puissance de calcul en fonction des besoins de chaque application à un instant donné ;
• diminution des risques liés au dimensionnement des serveurs lors de la définition de l'architecture d'une application, l'ajout de puissance (nouveau serveur, etc.) étant alors transparent.

Dépend de l'implémentation de la machine virtuelle. En cas d'installation brute sur un seul serveur on peut constater les problèmes suivants :

• l'accès aux ressources des serveurs hôtes via la couche d'abstraction matérielle nuit aux performances, et l'exécution de n'importe quel logiciel virtualisé consommera davantage de ressources qu'en mode natif ;
• en cas de panne d'un serveur hôte, l'ensemble des machines virtuelles hébergées sur celui-ci seront impactées. Mais la virtualisation est souvent mise en œuvre avec des redondances, qu'elle facilite ;
• la mise en œuvre est complexe et demande un investissement initial ;
• il y a des contraintes d'administration spécifiques (déploiement, sauvegarde…).

Une bonne part des travaux sur la virtualisation fut développée au centre scientifique de Cambridge d'IBM en collaboration avec le MIT, où fut mis au point le système expérimental CP/CMS, devenant ensuite le produit (alors nommé hyperviseur) VM/CMS. Voir IBM 360 et 370. Par la suite, les mainframes ont été capables de virtualiser leurs systèmes d'exploitation avec des technologies spécifiques et propriétaires, à la fois logicielles et matérielles. En 1979 fut annoncé par exemple sur les IBM 4331 et 4341 un accélérateur VM optionnel et microcodé.

Dans la deuxième moitié des années 1980 et au début des années 1990, on a créé des embryons de virtualisation sur des ordinateurs personnels. Ces solutions pouvaient être soit purement logicielles, soit couplées à du matériel additionnel (ajout de processeur, carte réseau, etc.). Et c'est sur des ordinateurs Amiga équipés de processeurs hétérogènes comme le 80386 et 80486, 68xxx, et PPC qu'il était possible de lancer d'autres OS comme Windows, Mac OS, voire Linux, le tout en multitâche sous AmigaOS. C'est sur cette machine en avance sur son temps que la technologie de virtualisation a été pleinement exploitée et encore inégalée aujourd'hui. Pour les PC, il y avait des émulateurs comme le SideCar et PC Task. Sur Macintosh, Emplant et ShapeShifter. Les grands Unix ont suivi avec les architectures NUMA des Superdome d'HP (PA-RISC et IA-64) et des E10000/E15000 de Sun (UltraSparc).

Dans la seconde moitié des années 1990, les émulateurs sur x86 des vieilles machines des années 1980 ont connu un énorme succès, notamment les ordinateurs Atari, Amiga, Amstrad et les consoles NES, SNES, Neo-Geo AES. La société VMware développa et popularisa à la fin des années 1990 et au début des années 2000 un système propriétaire de virtualisation logicielle des architectures de type x86 pour les architectures de type x86. Les logiciels libres Xen, KVM, QEMU, Bochs, Linux-VServer, Oracle VM VirtualBox et les logiciels propriétaires mais gratuits VirtualPC, Virtual Server et VMware Server ont achevé la popularisation de la virtualisation dans le monde x86. VMware a dernièrement rendu gratuite une version allégée de son hyperviseur phare ESX3i. Les fabricants de processeurs x86 AMD et Intel ont mis en œuvre la virtualisation matérielle dans leurs gammes dans la seconde moitié de l'an 2000.

L’ETSI a mis en place en novembre 2012 un groupe de travail [6] afin de standardiser le NFV (en), une nouvelle approche de la virtualisation, auquel participent de nombreuses sociétés spécialisées dans les technologies d’intelligence réseau (Qosmos, Procera Networks ou encore Sandvine) et des laboratoires de recherche universitaire (University of Campinos, University Carlos III of Madrid, University of the Basque Country, University of Patras, etc.)[7].

Afin d'avoir une idée théorique des performances des applications au sommet, il faut comparer verticalement l'empilement de couches. Il est possible d'élargir les schémas en rajoutant des environnements virtualisés consommant également des ressources de l'hôte.

Isolateur

Isolateur.

Un isolateur est un logiciel permettant d'isoler l'exécution des applications dans ce qui est appelé des contextes, ou bien zones d'exécution. L'isolateur permet ainsi de faire tourner plusieurs fois la même application dans un mode multi-instance (plusieurs instances d’exécution) même si elle n’était pas conçue pour ça. Cette solution est très performante, du fait du peu d'overhead (temps passé par un système à ne rien faire d'autre que se gérer), mais les environnements virtualisés ne sont pas complètement isolés. La performance est donc au rendez-vous, cependant on ne peut pas vraiment parler de virtualisation de systèmes d’exploitation. Uniquement liés aux systèmes Linux, les isolateurs sont en fait composés de plusieurs éléments et peuvent prendre plusieurs formes.

Par exemple, en logiciels libres : Linux-VServer (isolation des processus en espace utilisateur), chroot (isolation changement de racine), BSD Jail (isolation en espace utilisateur), OpenVZ (partitionnement au niveau noyau sous Linux), LXC (usage des Cgroups du noyau Linux), Docker.

Noyau en espace utilisateur

Noyaux en mode utilisateur.

Un noyau en espace utilisateur (user-space) tourne comme une application en espace utilisateur de l'OS hôte. Le noyau user-space a donc son propre espace utilisateur dans lequel il contrôle ses applications. Cette solution est très peu performante, car deux noyaux sont empilés et l’isolation des environnements n’est pas gérée et l’indépendance par rapport au système hôte est inexistante. Elle sert surtout au développement du noyau.

Par exemple : User Mode Linux (noyau tournant en espace utilisateur) ; Cooperative Linux ou coLinux (noyau coopératif avec un hôte Windows) ; Adeos (micro noyau RT faisant tourner Linux en kernel-space non-RT) ; L4Linux (micro noyau RT faisant tourner Linux en kernel-space non-RT).

Hyperviseur de type 2

Hyperviseur de type 2.

Un hyperviseur de type 2[8] est un logiciel (généralement assez lourd) qui tourne sur l'OS hôte. Ce logiciel permet de lancer un ou plusieurs OS invités. La machine virtualise ou/et émule le matériel pour les OS invités, ces derniers croient dialoguer directement avec ledit matériel. Cette solution est très comparable à un émulateur, et parfois même confondue. Cependant l’unité centrale de calcul, c'est-à-dire le microprocesseur, la mémoire système (RAM) ainsi que la mémoire de stockage (via un fichier) sont directement accessibles aux machines virtuelles, alors que sur un émulateur l’unité centrale est simulée ce qui réduit considérablement les performances par rapport à la virtualisation.

Cette solution isole bien les OS invités, mais elle a un coût en performance. Ce coût peut être très élevé si le processeur doit être émulé, comme cela est le cas dans l’émulation. En échange cette solution permet de faire cohabiter plusieurs OS hétérogènes sur une même machine grâce à une isolation complète. Les échanges entre les machines se font via les canaux standards de communication entre systèmes d’exploitation (TCP/IP et autres protocoles réseau), un tampon d’échange permet d’émuler des cartes réseaux virtuelles sur une seule carte réseau réelle.

Par exemple : logiciels Microsoft (Microsoft VirtualPC, Microsoft Virtual Server), logiciels Parallels (Parallels Desktop, Parallels Server), Oracle VM VirtualBox (libre), logiciels VMware (VMware Fusion, VMware Player, VMware Server, VMware Workstation), logiciels libres (QEMU : émulateur de plateformes x86, PPC, Sparc, et bochs : émulateur de plateforme x86).

Hyperviseur de type 1

Hyperviseur de type 1

Un hyperviseur de type 1 est comme un noyau système très léger et optimisé pour gérer les accès des noyaux d'OS invités à l'architecture matérielle sous-jacente. Si les OS invités fonctionnent en ayant conscience d'être virtualisés et sont optimisés pour ce fait, on parle alors de para-virtualisation (méthode indispensable sur Hyper-V de Microsoft et qui augmente les performances sur ESX de VMware par exemple). Actuellement l’hyperviseur est la méthode de virtualisation d'infrastructure la plus performante mais elle a pour inconvénient d’être contraignante et onéreuse, bien que permettant plus de flexibilité dans le cas de la virtualisation d'un centre de données.

Par exemple : Citrix Xen Server (libre), VMware vSphere (anciennement VMware ESXi et VMware ESX), Microsoft Hyper-V Server, Parallels Server Bare Metal, Oracle vm (gratuit), KVM (libre).