Les hébergeurs diffèrent de par leurs offres, leur taille, etc., mais également de par leurs choix d’infrastructures. Or ces derniers, qui sont un vecteur majeur de l’efficacité d’une offre d’hébergement, sont souvent peu connus. NBS System crée donc une série d’articles présentant ses infrastructures et les outils utilisés, pour plus de transparence et pour faire connaître cette partie cachée du secteur de l’hébergement informatique. Après notre article sur les reverse proxies, puis celui sur les pare-feux et les load balancers, nous nous tournons aujourd’hui vers les hyperviseurs.

Avant tout chose, il est important d’élargir le sujet afin de bien définir les termes qui seront utilisés dans l’article. C’est pourquoi nous commencerons par exposer le concept du Cloud, puis nous expliquerons la virtualisation, et enfin, nous nous intéresserons aux caractéristiques des hyperviseurs.

Schema infra_hyperviseur

Le concept du Cloud

Ces temps-ci, un mot est sur toutes les lèvres : le Cloud. LeCloud icon concept du Cloud est le suivant : avoir accès à un service potentiellement mondial (stockage de données, accès à des ressources de calcul (CPU), des services Web ou mails…), sans se préoccuper de la position physique de ses données à un instant T. Pour faire simple, il s’agit de créer de nouveaux systèmes informatiques sans prendre en compte les contraintes opérationnelles et techniques sous-jacentes (datacenters, logistique, équipes humaines…). D’où le nom « Cloud » : dans l’imaginaire collectif, les données sont dans un « nuage », elles ne sont pas rattachées à un emplacement physique.

Cette caractéristique donne donc au Cloud trois dimensions importantes : souplesse, agilité et évolutivité. En effet, si l’on supprime les contraintes, tout devient possible… Les équipes peuvent désormais se focaliser sur l’évolution et l’amélioration des services plutôt que sur le maintien des infrastructures sous-jacentes.

Pour cela, le Cloud s’appuie sur diverses technologies de virtualisation, qui lui apportent ce niveau d’agilité et d’évolutivité qui fait notamment son succès.

Qu’est-ce que la virtualisation ?

La virtualisation consiste, dans sa définition générale, à faire fonctionner un ou plusieurs systèmes sur une ou plusieurs machines physiques, plutôt que de se limiter à un système par machine. On peut ainsi avoir, par exemple, trois serveurs sur une machine physique. Il faut ici s’arrêter un moment pour définir le vocabulaire qui sera utilisé dans la suite de l’article :

  • Host : un host représente un système physique. C’est le système « originel » d’une machine.
  • Guest : un guest représente un système virtuel. C’est un système qui a été virtualisé sur un host. Ce peut être une machine virtuelle (VM ou Virtual Machine) telle qu’un serveur, mais également d’autres types de systèmes (routeur, commutateur…)

Afin de mieux comprendre la virtualisation, penchons-nous un moment sur son histoire.

Chroot

Schéma ChrootLa première méthode mise au point permettant de simuler plusieurs systèmes sur une machine physique se nomme chroot (prononcer C-H-root, pour CHange ROOT). Ici nous ne parlons pas encore de « guest » :  en effet, cette méthode consiste à déployer un ou plusieurs processus système dans une sous-arborescence isolée du système host (imaginez un système d’exploitation « fils » dans un dossier du système « père »), avec les caractéristiques suivantes :

  • Le host et les processus du chroot utilisent le même noyau (kernel).
  • Le host peut intervenir sur les processus du chroot , mais l’inverse n’est pas vrai.

Le chroot n’est donc pas à proprement parler de la virtualisation. Son objectif est de faire fonctionner, au sein d’une même machine, des processus qui ne doivent pas cohabiter. Cela est possible grâce à l’isolation de ces processus les uns par rapport aux autres, action permise par le chroot.

Dédoublement de piles réseau

Une autre technique tournant autour du principe de la virtualisation est le dédoublement de piles (stacks) réseau. Elle consiste à créer, directement dans le noyau, plusieurs réseaux. En effet, techniquement, un clonage de la stack réseau (ou stack IP) du noyau fournit des noms de domaine et permet ainsi d’obtenir deux réseaux différents. Ces stacks réseau sont définies et configurées par l’espace utilisateur (appelé userland. C’est ce ce qui, dans la machine, n’est pas le noyau) : il est donc possible, par exemple en utilisant en parallèle le Chroot, de créer deux stacks au total, une par espace (host et guest). Cela apporte encore plus de souplesse, notamment au niveau du routage.

Les conteneurs

Le chroot et le dédoublement de stack réseau ne sont cependant que les premiers balbutiements de ce qui aboutira à la virtualisation telle qu’on la connaît aujourd’hui. Le début de la virtualisation moderne se marque par la technique des conteneurs, inaugurée avec Linux Vserver puis OpenVZ sur Solaris. Aujourd’hui, Docker est l’un des systèmes de conteneurs les plus connus. Cette méthode, comme son nom l’indique, se base sur des conteneurs. Ce sont eux qui vont contenir les systèmes guests ; ce sont des systèmes clé en main, qui gèrent automatiquement de nombreux aspects techniques. L’isolation entre les systèmes est ici très poussée, et l’administrateur peut contrôler la consommation des ressources de chacun, ce qui n’était pas possible avec la méthode chroot. Ce ne sont pas, cependant, les seules différences entre ces deux méthodes :

  • ConteneurLe host et les guests ne peuvent pas interagir entre eux : les conteneurs apportent une réelle isolation entre les différents systèmes. C’est cette caractéristique qui nous fait entrer dans l’ère de la virtualisation moderne.
  • Les conteneurs sont facilement déployables sur le host : ainsi, la méthode des conteneurs permet de rendre la virtualisation et les machines plus accessible, notamment pour les personnes n’ayant pas de compétences techniques « système ».
  • Ce fait implique également qu’un conteneur peut être déployé ou détruit instantanément selon les besoins. Ils apportent donc une souplesse incomparable en termes de manipulation et de maintenance.

La seule caractéristique qui ne change pas, c’est l’utilisation commune du noyau : on ne peut donc toujours pas avoir des systèmes d’exploitation différents au cœur d’une même machine physique.

Les hyperviseurs

Hyperviseur schemaLa méthode que nous utilisons est encore un peu différente, en cela que le host et les guests ne partagent pas le noyau. Chaque système, qu’il soit physique ou virtuel, a son propre noyau. L’isolation entre les systèmes est donc ici complète. Cependant, cela pose un problème : comme représenté sur le schéma, le noyau d’un guest n’est pas directement en contact avec le matériel physique sous-jacent ; il ne peut donc pas interagir en l’état avec la machine (CPU, carte réseau…), comme c’est le rôle du noyau.

En revanche, le noyau du host a cette possibilité. Il faut donc créer une interface de communication entre celui-ci et les noyaux des guests, un intermédiaire envoyant au noyau du host les requêtes des noyaux des guests : l’hyperviseur.

Les modes de virtualisation

Il existe deux modes de virtualisation : la para-virtualisation et la HVM (Hardware Virtual Machine, ou virtualisation hardware des processeurs).

Avec l’utilisation du mode HVM, le noyau du guest passe nécessairement par l’hyperviseur pour pouvoir accéder à la machine physique. La machine virtuelle est complètement isolée, elle considère l’hypêeviseur comme une machine physique en elle-même : il virtualise les ressources nécessaires. La machine virtuelle s’adresse donc à lui comme si elle parlait directement avec le hardware. L’avantage de cette technique est que l’on peut avoir un host Linux et un guest Windows, puisque les noyaux du guest et du host n’ont aucune interaction : ils peuvent donc venir de systèmes d’exploitation différents. L’inconvénient, c’est qu’avoir un intermédiaire rallonge le temps de traitement des actions, et diminue donc la performance des machines. C’est ce qui a été représenté dans le schéma ci-dessus, légendé « hyperviseur ».

Avec la para-virtualisation, certaines demandes passent par l’hyperviseur, sauf celles à destination de composants choisis, comme la carte réseau, les CPU ou encore les paravirtdisques (dans les cas de machines possédant un disque). En effet, ces dernières sont envoyées sur le matériel, via le noyau du host, sans passer par l’hyperviseur. L’avantage et l’inconvénient de cette technique sont à l’exact inverse de ceux de HVM : elle apporte de bonnes performances en supprimant l’intermédiaire, mais ne permet pas d’utiliser un système d’exploitation différent sur les guests et sur le host, puisque les 2 noyaux interagissent ensemble. Nous avons représenté cette technique grâce au schéma ci-contre, simplifié avec un seul guest, et en ne représentant que les interactions concernant les noyaux et les hyperviseurs.

L’hyperviseur

Qu’est-ce qu’un hyperviseur ?

Comme indiqué ci-dessus, un hyperviseur est une partie du noyau d’un host recevant les demandes des noyaux des guests et les transmettant à la machine. Sa performance joue donc en grande partie sur celle des guests.

L’hyperviseur n’est donc pas, au contraire des reverse proxies, load balancers et pare-feux évoqués dans les articles précédents, une machine entière. Il fait partie des hosts : c’est sur ces derniers que des optimisations sont faites pour avoir la meilleure performance possible. Nous appellerons ces machines des hosts hyperviseurs.

Chez NBS System

Xen_logoChez NBS System, nous utilisons la technologie Xen, que l’on compile avec le noyau de nos hosts.

Nous utilisons également à 90% environ la para-virtualisation sur notre parc, qui fonctionne sous Linux. Les 10% restants sont en HVM et nous permettent de faire tourner quelques machines Windows ou Unix pour des usages internes spécifiques.

NB : dans les dernières versions de Xen, un mode hybride para-virtualisation / HVM (PVHVM) est disponible, offrant tous les avantages des deux méthodes sans les inconvénients. NBS System envisage d’utiliser cette option dans le futur.

Nos optimisations

Caractéristiques du host hyperviseur

Icone hyperviseurNos hosts sont des machines comprenant 40 CPU et 192 Go de RAM, et sont exemptes de disque. Cette absence de stockage physique découle d’une volonté de notre part d’apporter la meilleure résilience possible à nos hosts. En effet, il suffit au host, pour fonctionner, d’avoir accès à de la RAM, des CPU et des cartes réseau : tout le reste étant optionnel, nous l’avons retiré.

Nos lecteurs les plus fidèles reconnaissent ici le choix que nous avons également fait pour nos reverse proxies !

La création d’un host hyperviseur

Avant de continuer la lecture, si vous ignorez comment une machine peut se passer de disque, nous vous conseillons de lire le chapitre « comment nos RP fonctionnent sans disque » de notre article sur les reverse proxies (10 lignes). Nous utiliserons notamment dans la suite de l’article les termes PXE et InitRD, qui sont définis dans ce chapitre.

Au démarrage d’une machine, le PXE reçoit un signal de la carte réseau et lui indique où trouver l’InitRD utilisé pour la découverte de nouveau matériel et le noyau nécessaire à son démarrage. En parallèle, il collecte les informations sur la machines contenues dans le signal : adresse MAC, numéro de série, type de matériel… Cela lui permet de reconnaître que la machine en question est physique, ce qui ne peut être, chez NBS System, qu’un host hyperviseur. Il référence alors ce nouvel host dans les inventaires matériel, et fait redémarrer la machine.

Ainsi, quand celle-ci redémarre, elle envoie à nouveau un signal reçu par le PXE. Ce dernier reconnaît alors l’adresse MAC de la machine, qu’il vient d’enregistrer : il sait qu’il a affaire à un host hyperviseur. Il lui envoie alors les informations pour récupérer les éléments suivants :

Noyau et InitRD (ce sont les mêmes quelle que soit la machine)

Ligne de commande spécifique, unique par machine, contenant notamment le nom du host, ses adresses IP dédiées et des informations sur ses fonctions de host hyperviseur. Celle-ci est créée lors de l’enregistrement du host.

Xen, soit l’hyperviseur en lui-même, pour contrôler les fonctions de virtualisation sur la machine.

On obtient ainsi un host prêt automatiquement, ce qui évite une configuration manuelle de chaque nouvelle machine mise en route ! En parallèle, le host est enregistré comme « actif » via des mécanismes internes, et est alors marqué comme disponible pour la production sur nos outils de gestion du parc.

En production

Une fois le host prêt, pour pouvoir créer une machine virtuelle, l’hyperviseur doit avoir accès à un fichier de configuration. Une possibilité pour l’administrateur est de passer par le réseau et de fournir ce fichier directement sur la machine, à la main, mais cela présente des risques d’erreur humaine (oubli d’un fichier, double déploiement…).

Chez NBS System, nous utilisons un système de NFS (Network File System) : c’est un espace de stockage des fichiers, situé sur nos Netapps, pouvant être partagé entre plusieurs machines. Ce n’est qu’une des nombreuses solutions disponibles !

Une fois liée à ce NFS (ces liens sont effectués au démarrage du real system de la machine, c’est-à-dire au démarrage du vrai système d’exploitation), le host hyperviseur a accès aux fichiers comme s’ils étaient sur sa mémoire locale. Ce sont ainsi les logs (journaux), les fichiers de configuration des machines virtuelles, et différents outils internes qui sont enregistrés sur le NFS.

Création d’une machine virtuelle

Comment, alors, déploie-t-on une machine virtuelle ?

Nous utilisons chez NBS System des outils de déploiement, à savoir Salt. Salt est un outil de gestion de configurations et un système d’exécution à distance, c’est lui qui exécute la majorité des actions comme le montre le schéma ci-dessous.

Exploitation

  1. L’administrateur enregistre la machine virtuelle dans notre base de données interne (nom, ressources nécessaires, datacenter…)
  2. L’administrateur donne à Salt la commande de déployer la machine virtuelle en question
  3. Salt va alors récupérer dans la base de données toutes les informations rentrées par l’administrateur et générer :
    1. un fichier de configuration Xen : il contient notamment des informations sur les ressources dédiées à la machine, ainsi que sur la location où trouver un noyau, un InitRD, et la ligne de commande dédiée à la nouvelle machine
    2. un File System pour la machine virtuelle, contenant déjà des fichiers utiles à la machine virtuelle.
  4. Salt les envoie ensuite au NFS, qui va stocker ces fichiers.
  5. Dernière étape, Salt envoie au host choisi la commande pour démarrer une nouvelle machine virtuelle.

Une fois cela fait, l’hyperviseur va faire démarrer un guest et lui envoyer le noyau, l’InitRD et la ligne de commande qu’il a reçu dans son fichier de configuration. Une fois en marche, la machine virtuelle ira chercher son File System directement sur le NFS. Nous n’irons pas plus loin, le fonctionnement d’une machine virtuelle n’étant pas le sujet de cet article.

Conclusion

Au début de la virtualisation, la perte de performance par rapport à l’utilisation d’une machine physique était notable. Aujourd’hui, cette perte est minime par rapport aux nombreux avantages de la virtualisation : il n’y a donc plus aucune raison de ne pas passer le cap et utiliser cette méthode ! Les seuls freins sont les ressources (avoir une infrastructure adaptée à la virtualisation demande de l’outillage et des connaissances) ou l’utilisation de produits propriétaires ne soutenant pas cette technique (par exemple, Oracle refusait pendant un moment l’installation de son produit ailleurs que sur une machine physique, car celui-ci ne fonctionnait pas bien avec la virtualisation).

Vous connaissez donc maintenant le fonctionnement des hyperviseurs chez NBS System ! Retrouvez également nos articles sur les reverse proxies et sur les pare-feux & load balancers.

Source technique : Denis Pompilio

Lucie Saunois
Lucie Saunois
Passionnée d'informatique, en particulier de sécurité, depuis qu'elle a rejoint l'OT Group en 2015, Lucie se spécialise dans la vulgarisation technique pour permettre à tous d'appréhender ces sujets parfois complexes.