Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Les Principes de la Virtualisation

Les Principes de la Virtualisation

Partage d’un serveur

Un serveur est un ordinateur utilisé à distance depuis différents postes de travail, ou autres serveurs.  Il possède des ressources matérielles, principalement CPU, mémoire, disques et interfaces réseau. Ces ressources sont utilisées par des applications, non pas de manière directe, mais en s’appuyant sur un système d’exploitation.

La virtualisation de serveurs est un ensemble de techniques et d’outils permettant de faire tourner plusieurs systèmes d’exploitation sur un même serveur physique.   

Le principe de la virtualisation est donc un principe de partage : les différents systèmes d’exploitation se partagent les ressources du serveur.   

Pour être utile de manière opérationnelle, la virtualisation doit respecter deux principes fondamentaux :
Le cloisonnement :  chaque système d’exploitation a un fonctionnement indépendant, et ne peut interférer avec les autres en aucune manière.

La transparence : le fait de fonctionner en mode virtualisé ne change rien au fonctionnement du système d’exploitation et a fortiori des applications.   

La transparence implique la compatibilité:  toutes les applications peuvent tourner sur un système virtualisé, et leur fonctionnement n’est en rien modifié.

Pour ce qui est du cloisonnement, il existe bien sûr une interférence passive liée à la concurrence dans le partage des ressources.   Mais nous verrons  que ce partage peut être parfaitement contrôlé.

Screenshot from 2015-04-21 14:35:44

Architecture traditionnelle

Il existe depuis longtemps d’autres moyens de partager des ressources physiques.  En fait, les applications tournant sur un même serveur, en l’absence de virtualisation, se partagent déjà les ressources du serveur.  C’est l’une des missions du système d’exploitation que de permettre et d’administrer ce partage :   plusieurs applications se partagent les disques, le processeur, la mémoire, les accès réseau, et le système d’exploitation est le chef d’orchestre, gérant les règles de ce partage.

Alors, pourquoi ce partage ne suffit-il pas ? Pourquoi a-t-on besoin de virtualisation ?     

A cela, deux réponses.

La première relève de la rigueur du cloisonnement, au sein d’un même système, entre les différents contextes de travail.  Le fonctionnement natif de la plupart des systèmes ne permet pas un cloisonnement suffisamment étanche. Nous verrons qu’une des voies de la virtualisation consiste à renforcer le cloisonnement.

La seconde relève du système d’exploitation lui-même, et des configurations système. 

Il arrive couramment que les applications requièrent un système d’exploitation particulier, ou bien une configuration particulière du système, ou encore des composants logiciels majeurs qui ne peuvent pas cohabiter sur un même système d’exploitation.    

Dans tous ces cas de figure, le partage de ressources offert par le système lui même ne convient plus : on veut partager les ressources en dessous du système d’exploitation, de manière à faire cohabiter plusieurs systèmes d’exploitation sur le même serveur physique.

Objectifs et bénéfices

Le premier objectif de la virtualisation est économique.  
Partager les ressources physiques dont on dispose entre différents serveurs virtuels, permet de ne pas acheter plusieurs serveurs physiques, lorsqu’un seul a une capacité suffisante en termes de ressources.    
Le constat sous-jacent est que les serveurs sont souvent sous-utilisés.  On estime que dans un datacenter privé ordinaire, le taux d'utilisation moyen est de l'ordre de 10%, et qu'une utilisation généralisée de la virtualisation permet d'atteindre 35%.  C'est encore loin de 100, mais c'est quand même trois fois moins de serveurs.  
Parce que les serveurs commercialisés correspondent à un « quantum » minimal de puissance ;  vous pouvez certes ajuster la configuration mémoire, mais si votre besoin est seulement un dixième de processeur, il vous faut un processeur entier, et donc un serveur entier, qui sera alors sous-utilisé.
Par ailleurs, les besoins d’une application donnée peuvent varier dans le temps de manière extraordinaire. Soit à court terme, avec les heures de pointes dans une même journée. Soit sur le long terme, avec par exemple un environnement de développement mis en sommeil pour plusieurs mois, puis à nouveau utilisé pour une opération de maintenance.
Bien sûr, on peut aussi partager un serveur dans le temps, en sauvegardant toute la configuration logicielle, y compris le système d’exploitation, et en installant un autre système pour une autre utilisation.
C’est en fait ce que l’on faisait avant la virtualisation pour remettre en place l’environnement de développement d’un projet ancien afin d’y faire une opération de maintenance.
La réinstallation d’un système complet est une opération lourde, qui peut prendre plusieurs heures, et présente  un risque de petites variations de configuration. Aujourd’hui, on préfère conserver un environnement virtualisé prêt à l’emploi, qui ne consommera pratiquement aucune ressource, si ce n’est une part de l’espace disque.

Éviter de multiplier les serveurs physiques apporte des bénéfices en termes de coût d’acquisition, bien entendu, mais aussi en termes de coût de possession, tant au niveau de l’hébergement (rack, électricité, refroidissement, câblage, interfaces réseau), que de l’exploitation.

Mais la virtualisation apporte aussi des bénéfices qui ne sont pas directement liés au partage des ressources.   

Ainsi, la virtualisation permet de déplacer un serveur virtuel d’un hôte à un autre de manière très aisée, y compris sur des environnements matériels très hétérogènes, puisque les couches matérielles dans les serveurs virtuels sont le plus souvent génériques.

Cette capacité à agencer aisément et rapidement la répartition des serveurs virtuels sur un parc de serveurs physiques est évidemment une révolution dans l’administration d’un parc de serveurs.  D'une certaine manière, le serveur devient une ressource ordinaire, une « commodité », et au lieu de répartir des applications sur des serveurs, on fournit du serveur aux applications.

Avec certaines solutions de virtualisation, le déplacement s’effectue de manière totalement transparente pour le système invité.   Le délai de ce déplacement nécessite le transfert de l’espace disque et de la mémoire, et nous verrons que certaines technologies de virtualisation et certaines configuration de stockage permettent des transferts à chaud sans arrêt des applications.

Historique

Le besoin de partager les ressources physiques pour une utilisation optimale est bien sûr d’autant plus fort que ces ressources sont coûteuses, et c’était donc un domaine de recherche important dès les débuts de l’informatique transactionnelle.

La capacité à gérer plusieurs utilisateurs simultanément, en séparant leurs contextes de travail, est apparue dès les années 70, et s’est généralisée dans les années 80 avec les grands moniteurs transactionnels, tels que CICS.

Chaque utilisateur dialogue avec le serveur de manière indépendante, comme s’il était seul, et utilise donc une petite part des ressources du serveur, selon son besoin.  Néanmoins, cette séparation de contextes utilisateurs, que l’on retrouve bien sûr aujourd’hui avec les serveurs HTTP et les outils serveurs d’application du web, n’est pas appelée virtualisation.   En effet, si le contexte applicatif est propre à chaque utilisateur, le contexte logiciel est au contraire parfaitement homogène.

IBM figure parmi les pionniers de ces technologies avec l’hyperviseur CM/CMS utilisé dès les années 60, qui fut le père de VM/CMS dans les années 70, devenu aujourd’hui z/VM, qui permet de faire tourner y compris AIX ou Linux au sein d’une machine virtuelle sur mainframe.

Dans la seconde moitié des années 1990, le monde de la micro-informatique découvre  les émulateurs. La puissance des machines x86 leur permet d'émuler les  générations précédentes de machines.  Il devient alors possible d'émuler des machines Atari, Amiga, Amstrad ainsi que de nombreuses consoles.

A la fin des années 1990 la société VMware développe et popularise le produit du même nom, système propriétaire de virtualisation logicielle des architectures de type Intel x86, ouvrant la possibilité de mettre en place n'importe quel environnement x86 à des fins de tests ou de développement sans avoir besoin d'acheter une nouvelle machine.  Contrairement aux émulateurs cités précédemment, il est enfin possible de faire tourner les applications professionnelles destinées aux processeurs x86 dans une machine virtuelle.

Il faut citer aussi aux rangs des précurseurs, Qemu, créé par Fabrice Bellard, qui a ouvert la voie et sur lequel se sont appuyées la plupart des solutions open source.
Viennent ensuite les logiciels libres comme Xen, KVM, et OpenVZ, que nous décrirons plus en détail dans ce document.

Et pour finir les logiciels orientés poste de travail comme VMware Player ou VirtualBox ont achevé la popularisation de la virtualisation dans le monde x86.

Pour répondre aux nouveaux défis de la virtualisation, notamment en terme de performances, les fabricants de processeurs x86, AMD et Intel, ont implémenté dans leurs gammes de processeurs des instructions spécifiques améliorant les possibilités de virtualisation.  Ces processeurs ont commencé à être diffusés à partir de 2006.   Ils permettent une virtualisation avec un rendement proche de 100%. La course à la performance n'est cependant pas terminée, et de nouvelles technologies comme la virtualisation des IO sont encore en cours de généralisation.

Mais dans l'ensemble, la technologie à la base de la virtualisation est mature, et l'essentiel des efforts se concentre désormais sur les outils permettant de tirer profit de la virtualisation : que ce soit les outils de stockage, de sauvegarde, ou d'administration. Les offres estampillées « Cloud Computing » sont un bon exemple des possibilités offertes par une virtualisation dont le cycle de vie est entièrement automatisé.

Un peu de vocabulaire

Hyperviseur

L’hyperviseur est la couche logicielle qui s’insère entre le matériel et les différents systèmes d’exploitation.   C’est bien un composant clé, que l'on retrouve dans la plupart des technologies de virtualisation de bas niveau.

Ainsi, par rapport au schéma de base d’un serveur distinguant le matériel, le système d’exploitation, et ses applications :

Screenshot from 2015-04-21 14:48:04

L’hyperviseur vient s’insérer entre le matériel et plusieurs systèmes d’exploitation, de la manière suivante :

Screenshot from 2015-04-21 14:49:24

L’hyperviseur peut soit gérer lui-même toutes les ressources matérielles du serveur, soit s’appuyer pour cela sur un système d’exploitation existant. Dans ce dernier cas, on parle d’hyperviseur de type 2, comme figuré ci-après.

Screenshot from 2015-04-21 14:49:26

Espace noyau, espace utilisateur

Rappelons que l’on distingue, dans un serveur deux espaces :

  • L’espace noyau (kernelspace), qui inclut le noyau du système d’exploitation et ses drivers.
  • L’espace utilisateur (userspace), qui inclut tout le reste, incluant tous les composants systèmes de la distribution ainsi que les applicatifs spécifiques.
Screenshot from 2015-04-21 14:52:20

OS hôte, OS invité
Dans le cas d'un hyperviseur de type 2, on appelle « OS hôte » ou Host OS, l’OS sous-jacent, sur lequel s’appuie l’hyperviseur.

On appelle « OS invité » ou Guest OS, les OS des machines virtuelles.

Émulation

L’émulation consiste à simuler l’exécution d’un programme en interprétant chacune des instructions destinées au micro-processeur. Il est possible d’émuler ainsi n’importe quel processeur et l’environnement complet d’un serveur.

On a vu apparaître ainsi, dans les années 90, des émulateurs reproduisant fidèlement les premiers micro-ordinateurs tels que Amiga, ou Atari.    

L’émulation est la technique qui offre le plus haut niveau d’abstraction de la plateforme. Il faut rappeler en effet que toutes les autres techniques de virtualisation citées ont une exigence en commun : tous les exécutables doivent être compilés pour le processeur physiquement disponible sur le serveur.   

L’émulation lève cette contrainte car les instructions ne sont jamais exécutées par le processeur, elles sont interprétées en simulant le processeur.

Cette interprétation est coûteuse en performances, de sorte que l’émulation est rarement utilisée en dehors d’applications ludiques ou de recherche. Dans le cas de l’émulation des vieux matériels, le différentiel de puissance des processeurs sur 10 ans comblait largement la perte résultant de l’émulation.

Le projet QEMU est la principale solution open source de virtualisation par émulation. 

Performances et rendement

A l’évidence, puisqu’il y a partage des ressources physiques, chaque environnement virtuel dispose de ressources plus limitées que s’il avait un serveur physique dédié.   

Mais la question essentielle est : la somme des ressources allouées aux différents environnements virtuels est-elle égale aux ressources physiques disponibles ? Autrement dit : Quel est le surcoût (« overhead ») de la virtualisation ? On pense en particulier au surcoût en termes de CPU, car les autres ressources sont en général moins précieuses.   
Les bonnes solutions de virtualisation, appuyées sur des processeurs disposant d’instructions spécialisées, permettent un surcoût en performances qui est aujourd’hui négligeable, c’est à dire que le rendement est pratiquement égal à 1.

 En d’autres mots : la mise en œuvre d’environnements virtualisés n’implique presque pas de perte de performances.

Il faut souligner aussi que dans certaines applications de la virtualisation, de nombreux environnement peuvent être dormants, en attendant un usage futur. Dans ce cas leur consommation de ressource CPU est à peu près nulle, et leur consommation de RAM est très faible.

Sécurité

Dans la pratique, la virtualisation n’apporte aucune dégradation en termes de sécurité.

Certes, la sécurité du serveur physique sous-jacent est critique, car un accès console sur ce serveur, ou sur l’hyperviseur de la solution de virtualisation pourrait compromettre l’ensemble des serveurs virtuels hébergés.  Il est donc évidemment primordial d'y assurer un haut niveau de sécurité, et donc de bien distinguer en termes d’habilitations, l’administration du serveur physique et de la virtualisation d’une part, et l’administration des environnements virtualisés d’autre part.

A l’inverse, le contrôle administrateur (root) sur l’un des environnements ne donne aucun droit, ni aucune possibilité, même pour un intervenant malveillant, ni sur l’environnement physique et l’hyperviseur, ni sur les autres environnements.

Enfin, la bonne pratique, scrupuleusement appliquée par les bons administrateurs, est de séparer le réseau d'administration des serveurs physiques, et le réseau des VM par lequel arrive le trafic utilisateur.

Administration

Si la virtualisation est transparente pour les utilisateurs, pour les applications, et même pour les systèmes d’exploitation invités, elle ne l’est pas bien sûr pour l’administrateur qui en a la charge.

La mise en œuvre et l’exploitation des solutions de virtualisation requièrent une vraie expertise. Pour un administrateur système de bon niveau, maîtriser une solution de virtualisation demandera plusieurs jours de formation, et quelques semaines de pratique.

Contrôle des ressources

Une des grandes problématiques dans un environnement virtualisé est le contrôle dans l’attribution et dans le partage des ressources du serveur physique.

On peut souhaiter répartir les ressources disponibles soit de façon équitable, soit en privilégiant certains environnements par rapport aux autres.

Les règles dépendent bien sûr du domaine d’application. Si 10 sites Internet se partagent un serveur physique et que l’un connaît un pic de trafic, on peut souhaiter lui laisser prendre 90% de la CPU tant que les autres n’en ont pas usage. A l’inverse, si un hébergeur a vendu 1/10ème de serveur à l’un de ses clients, il doit être en mesure de garantir que le client aura toujours son quota, quelle que soit la demande des autres clients.

Dans tout les cas les différents produits de virtualisation implémentent des mécanismes permettant d'assurer cette répartition, et d'éviter qu'un serveur ne pénalise les autres en consommant toutes les ressources de la machine physique sur laquelle ils s'exécutent.

Les quatre ressources principales que l'on souhaite contrôler sont :

  • Le CPU : un ordonnanceur spécifique est généralement en charge de répartir la charge du ou des processeurs entre les différents serveurs virtuels. La plupart des technologies permettent d'attribuer des  poids, privilégiant ainsi un serveur par rapport à l'autre ce qui permet d'assurer un minimum de puissance disponible, tout  en tirant profit des ressources maximales de la machine physique.
  • La mémoire : la mémoire est la ressource la mieux maîtrisée par l'ensemble des technologies de virtualisation. La mémoire que l'on souhaite attribuer à un serveur virtuel est souvent réservée à la création.
  • Le stockage : les différents produits de virtualisation peuvent s'appuyer sur différents types de stockage, adaptés à différentes échelles, tels qu'un simple répertoire, une image binaire d'un disque dur, ou un volume logique dans un SAN. L'espace disque disponible est connu à l'avance et peut être limité. De plus, une priorisation des accès est généralement possible pour favoriser certains environnements (par exemple les bases de données).
  • Le réseau : c'est la ressource la moins bien gérée par les technologies actuelles de virtualisation. Dans les produits présentés ici, aucune limitation de bande passante réseau n'est possible. En revanche, contrairement aux autres ressources, il est possible de contrôler le réseau en amont, au moyen d'un routeur implémentant des technologies de Qualité de Service.

Licences et support

La virtualisation permet d'exécuter des OS supplémentaires, et aussi d'en faire des multiples copies, backups, etc. Cela pose le problème des licences, qui ne sont le plus souvent pas prévues pour une utilisation en machines virtuelles. Il faut donc faire attention à ce problème. Microsoft Windows, par exemple, permet de licencier un certain nombre d'installations, et autorise d'avoir autant de machines virtuelles que l'on souhaite, du moment qu'on n'en exécute jamais plus simultanément que le nombre autorisé par la licence.
De même, il est fréquent que les éditeurs de logiciels ne supportent pas telle ou telle configuration matérielle, ou technologie de virtualisation. A l'inverse, certains logiciels sont certifiés compatibles avec Xen ou VMWare ESX. Dans les faits, plus la technologie de virtualisation est intrusive pour le système invité, moins il est probable qu'elle soit supportée par les éditeurs.