Quels sont les types de virtualisation ? A quoi celà correspond-il dans la vraie vie ?
Vous êtes perdus au milieu du jargon de la virtualisation ?
Je vous explique.
Le niveau zéro de la virtualisation : pas de virtualisation.
Lorsque l’on parle de virtualisation, il faut déjà définir ce qu’est un environnement non virtualisé. Ceci était encore la norme il y a quelques années.
En gros, pour toute machine/serveur physique on a un système d’exploitation (windows, linux ou autre) et des applications qui tournent sur ce système.
La machine physique :
- S’installe dans une salle serveur, dans une armoire
- Consomme directement de l’électricité
- Chauffe et doit donc être refroidie
- Doit être cablée physiquement par un opérateur
- A une durée de vie limitée à celui de son matériel
- Est physiquement connectée à un ou des réseaux
- Toute ressource non utilisée est perdue, car le matériel s’use même s’il n’est pas utilisé.
Le système d’exploitation :
- Est installé directement sur la machine physique
- A une durée de vie inférieure ou égale à celle du matériel
- Doit être installé à chaque fois (de façon automatisée ou non)
- Utilise toutes les ressources de la machine physique
- Ne peut obtenir de ressources supplémentaires que s’il y a intervention physique sur la machine hôte.
L’application :
- S’exécute à même le système d’exploitation
- Doit partager la quantité de ressources (cpu, ram, réseau) laissée libre par le système d’exploitation avec les autres applications.
- Peut avoir des conflits avec d’autres applications sur des ressources partagées (ports, fichiers, autres)
- Est dépendante des librairies installées sur le système.
- Ses dépendances peuvent entrer en conflit avec celles d’autres applications ou du système d’exploitation
Dans ce fonctionnement, chaque serveur est unique. Habituellement, il sont gérés en petits nombres par des administrateurs systèmes qui veillent sur chacun d’eux, leur donnent des petits noms, etc… Certaines équipes les gèrent en nombre plus conséquents, mais le constat de la gestion reste le même. On gère les serveurs comme des animaux de compagnie : ce sont des pets (animaux de compagnie en anglais).
La virtualisation niveau 1 : Les hyperviseurs
Les contraintes étant grandes pour les ajouts de serveurs physiques, notamment au niveau des budgets, ainsi que la piètre optimisation de leur cycle de vie et de leurs ressources, ont poussé les équipes systèmes à changer leur fusil d’épaule.
L’hyperviseur est né de cette volonté de mutualiser les ressources. Il en existe de nombreux comme ESX (avec ou sans “i” à la fin) de VMWARE, VIRTUALBOX, PROXMOX et XEN, pour les plus connus
Reprenons notre schéma précédent :
Sur ce schéma, nous avons toujours la machine physique ( Et il y en aura toujours, quoiqu’il arrive, l’informatique c’est pas magique, même en “serverless” ), sur laquelle est installée un hyperviseur, en lieu et place du système d’exploitation sur le schéma précédent.
Je vais vous spoiler la suite : l’hyperviseur est un système d’exploitation. Il a cependant plusieurs particularités. Ce système est fait pour émuler des machines physiques. En d’autres termes, il fait tourner des programmes qui sont censés offrir les mêmes fonctionnalités à des systèmes d’exploitation que ne le feraient des machines physiques.
Le but de ces programmes, c’est de faire croire aux systèmes d’exploitation que nous installerons dessus qu’ils sont des machines physiques, avec leurs propres systèmes de fichiers, processeurs, mémoire vive, réseau, etc…
L’hyperviseur est capable d’émuler les machines ainsi que l’infrastructure réseau les accompagnant. Techniquement, sur un hyperviseur, on peut faire un système d’information complet avec des switchs réseaux, des serveurs, des applications installées sur ces serveurs. Tout ceci est d’une redoutable efficacité.
En connectant plusieurs hyperviseurs, on peut créer des infrastructures conséquentes à peu de frais. Pour 450€/mois, j’avais à une époque sur 3 serveurs physiques OVH avec entre 55 et 70 machines virtuelles qui chacune avait son système d’exploitation et ses applications.
Les VM, les machines virtuelles, fonctionnent comme suit :
La machine virtualisée ressemble beaucoup à une machine installée sans virtualisation. Elle se comporte d’ailleurs de la même façon. La seule différence à son niveau est qu’elle aura quelques applications et pilotes installés pour optimiser son fonctionnement en environnement virtualisé.
Les avantages d’un hyperviseur sont :
- Les machines virtuelles ne sont plus liées à l’hôte physique : on peut les déplacer, sauvegarder, dupliquer, détruire sans impacter la machine physique.
- Les déplacements de machines d’un hyperviseur à l’autre peuvent se faire à chaud sur certains types d’hyperviseurs. (Testé en perdant un seul ping sur la machine pendant la migration.)
- On mutualise les ressources disponibles (balooning) : on provisionne plus de ressources virtuelles qu’il n’en est disponible physiquement. On considère que toutes les machines ne consomment pas 100% des ressources, 100% du temps, mais qu’elles ont chacune leurs pics d’activité, qui ne sont pas forcément simultanés.
- Il n’est pas nécessaire d’installer physiquement un serveur pour chaque machine virtuelle. Les installation se font à partir de templates (gabarits, images préinstallées) et peuvent donc se faire à distance.
- Le balooning et les déplacements à chaud peuvent permettre de limiter la perte d’activité en basculant automatiquement les machines virtuelles tournant sur un hyperviseurs crashé sur ses voisins. Une machine physique qui lâche n’est plus obligatoirement associée à une perte de service.
- la simplification de gestion permet également de ne pas avoir toutes les machines critiques en double, économisant de précieuses ressources matérielles et financières.
Grâce à tous ces avantages, la porte est ouverte à une gestion standardisée des serveurs. Un concept devops important ces dernières années est le “PET Vs CATTLE” .
D’un côté, le PET (animal de compagnie) est un serveur, physique ou virtuel, géré aux petits oignons, qui porte un nom, et que le/les admins réparent quand il est cassé.
De l’autre, le CATTLE (bétail) : Chaque serveur est standardisé et les procédure d’installation automatisées permettent sa gestion comme une tête de bétail. Il n’a plus de gestion propre. S’il est cassé, il est remplacé.
Maintenant, les inconvénients d’un hyperviseur :
- Ajout d’une couche supplémentaire entre la machine physique et le système d’exploitation de la VM, donc moins de ressources disponibles au total, dûs à la consommation de l’hyperviseur.
- Plus de difficultés à accéder à certaines ressources de la machine physique, comme des cartes physiques spécifiques, la console d’administration (qui est naturelle sur une machine physique, vu qu’elle apparait sur l’écran connecté dessus), ports usb ou les GPU. Tout ceci n’est pas insurmontable, mais devient non trivial.
- L’hyperviseur, bien que souvent accompagné d’une interface graphique simple d’usage, reste un environnement très complexe. J’ai déjà perdu pendant une semaine un cluster de 3 hyperviseurs (avec 70 machines comme cité plus haut) à cause d’un bug au niveau du réseau et d’une carte réseau fantôme non repertoriée. Ce cas est heureusement rare. (1 fois en 6 ans de gestion d’hyperviseurs)
Niveau supérieur, la virtualisation par conteneurs
Dernier point de ce billet, les conteneurs.
Le plus connus des systèmes de gestions de conteneurs est sans conteste Docker. ( Voir mon billet Pourquoi aucun nouveau projet ne devrait voir le jour sans docker)
Comment ça marche et comment s’en sert-on ?
La virtualisation par conteneur crée un simili de machine virtuelle, bien plus légère qu’une machine virtuelle classique, car elle se sert du noyau du système d’exploitation sur lequel elle est installée. Elle en est donc dépendante de celui -ci, mais en contrepartie, elle n’embarque que le strict minimum, d’où sa légèreté.
On installe sur le système d’exploitation un démon/service , comme dockerd, et ce démon crée des conteneurs isolés les uns des autres, chacun ayant son environnement et son système de fichiers. Le démon se charge également d’émuler un réseau entre les conteneurs, l’hôte et l’extérieur.
L’isolation des conteneurs est assurée grâce à des fonctionnalités directement implémentées dans le noyau du système d’exploitation.
L’immense avantage est que l’application ne tourne pas, fonctionnellement, sur la machine hôte, bien qu’elle en utilise les ressources. Elle ne dépend pas des librairies système installées et ses propres dépendances n’affecteront pas le système. ( Pour approfondir, de nouveau, voir mon billet Pourquoi aucun nouveau projet ne devrait voir le jour sans docker)
Ce type de virtualisation légère peut être associé à la virtualisation lourde par hyperviseur. En effet, on peut démarrer des conteneurs dans une machine virtuelle, aussi bien que sur une machine physique.
The next level : Kubernetes, swarm, etc…
L’étape suivante de la gestion des conteneurs consiste à les organiser sans plus se soucier de l’infrastructure sous-jacente. Le principe est de les faire tourner sur les machines hôtes qui seront standardisées, jusqu’aux applications et n’ayant pour but que de faire tourner des conteneurs, et gérés de façon standardisée par une tour de contrôle. La tour de contrôle recevra les demande d’allocation de ressources de notre part et choisira automatiquement où faire tourner les applications dont nous auront besoin.
Un slave kubernetes, la machine qui fait tourner les conteneurs avec les applications dans k8s, peut être schématiquement représentée comme ceci :
C’est une machine normale sur laquelle on installe la partie cliente de kubernetes. Il tient au courant sa tour de contrôle des ressources disponibles et des conteneurs tournant et répond à des demandes de ressources. il prend les commandes de la machine pour y faire tourner les conteneurs demandés par la tour de contrôle.
Swarm et mesos fonctionnent selon un schéma équivalent. On intéragit avec les masters (la tour de contrôle distribuée) et le système se charge de déployer les applications où bon lui semble, avec le nombre d’instances voulu et assure de fournir un chemin pour y accéder simplement.
C’est assez bluffant comme concept, mais ça marche.
Ainsi, on déploie des applications “quelquepart” et…. c’est tout. !
Je reviendrai dans un prochain billet sur Kubernetes pour vous expliquer ça plus en détail.
Et le cloud dans tout ça ?
Aujourd’hui, les offres fournies par les provider de cloud sont souvent mixtes.
Si on prend l’exemple d’amazon AWS :
- EC2 : hyperviseurs de type lourds
- ECS : Conteneurisation docker en standalone : c’est une solution simple pour faire tourner quelques conteneurs
- EKS : Solution kubernetes hébergée
- Lambda : on se contente de donner l’application qu’on veut voir tourner et amazon gère pour nous. Celà utilise les solutions vues précédemment
On se rend compte que les technos et concepts derrière les plateformes des providers sont complexes et imbriquées et qu’il est difficile des les classer. Globalement, plus vous avez de connaissances, plus vous pouvez vous permettre de prendre des services de bas niveau, qui seront moins chers.
Les providers de cloud, vu leur volumes, ont tendance à développer leurs propres systèmes, comme amazon avec nitro, leur nouvel hyperviseur, qui promet de faire tourner les machines virtuelles aussi vite que si elles étaient des machines physiques.
En conclusion
La virtualisation existe depuis longtemps et est largement utilisée. Aujourd’hui, cependant, il faut savoir choisir avec efficacité le niveau que vous allez choisir pour vos applications. Quel niveau de détail et de maitrise attendez-vous ? Est-ce rentable pour votre entreprise, votre projet ?
Aujourd’hui, tout le monde veut partir vers les conteneurs, par effet de mode. Mais ce n’est pas la solution à tout.
L’écosystème est riche. Utilisez-le selon vos besoin et vos compétences.
