La virtualisation : exercices corrigés de Bac pro CIEL

Repérer ce qui est installé directement sur le matériel du poste : c'est Debian. Debian est donc le système hôte.³

Les deux machines lancées par le logiciel de virtualisation (Windows et la seconde Debian) sont les systèmes invités.

Une machine virtuelle n'a pas de matériel propre : elle utilise les ressources de l'hôte. Quand l'hôte s'arrête, les deux machines virtuelles s'arrêtent avec lui.³

Elle est dite virtuelle parce que son matériel (processeur, disque, carte réseau) est simulé par le logiciel, au lieu d'être une pièce réelle dédiée.³

A. Vrai. Dans la conteneurisation, c'est le noyau de l'hôte qui permet l'existence de plusieurs espaces utilisateur isolés.⁴

B. Faux. Un conteneur ne peut pas héberger un système invité différent de celui de l'hôte ; sous Linux, on peut varier les distributions mais pas installer Windows.⁴

C. Vrai. Docker et Podman font partie des outils de conteneurs cités.⁴

D. Faux. Passer par la couche d'abstraction nuit aux performances : le logiciel virtualisé réclame davantage de ressources qu'en exécution native.³

E. Vrai. Ces trois outils sont donnés comme exemples de virtualisation complète.⁴

Charge totale en pourcentage de la capacité d'un serveur : $15 \times 15\,\% = 225\,\%$, soit 2,25 serveurs entiers.

Charge utile par hôte : 70 %, soit 0,7 serveur entier.

Nombre d'hôtes nécessaires : $2{,}25 \div 0{,}7 \approx 3{,}21$.

On ne peut pas acheter 0,21 machine : on arrondit au nombre entier supérieur, donc 4 hôtes.

Contrôle : 4 hôtes à 70 % offrent 2,8 serveurs entiers de capacité utile, ce qui couvre bien les 2,25 nécessaires ; avec 3 hôtes on n'aurait que 2,1.

Puissance avant regroupement : $15 \times 200 = 3\,000$ W.

Puissance après regroupement : $4 \times 200 = 800$ W.

Puissance économisée : $3\,000 - 800 = 2\,200$ W.

Énergie économisée sur l'année : $2\,200 \times 8\,760 = 19\,272\,000$ Wh.

Conversion : $19\,272\,000 \div 1\,000 = 19\,272$ kWh.

Vérification de l'hypothèse : elle est réaliste dans le sens où un serveur chargé à 15 % consomme à peu près autant qu'un serveur chargé à 90 %.³

Mémoire disponible pour les invités : $64 - 4 = 60$ Go.

Nombre de machines : $60 \div 6 = 10$.

La division tombe juste : 10 machines occupent exactement 60 Go, sans reste.

Remarque : le logiciel virtualisé consomme davantage de ressources qu'en exécution native, donc en pratique on garde une petite marge supplémentaire.³

Espace pour les machines virtuelles : $10 \times 20 = 200$ Go.

Espace pour les conteneurs : image de base $4$ Go, plus $10 \times 0{,}5 = 5$ Go de données propres, soit $4 + 5 = 9$ Go.

Gain : $200 - 9 = 191$ Go.

Explication : dans certaines implémentations, les partitions partagent un système de fichiers standard et ne créent leur propre copie que pour les fichiers qu'elles modifient, ce qui économise de la place.⁴

Machines touchées : celles de l'hôte en panne, donc 4 sur 12, soit un tiers du parc.³

Machines à relancer : 4, réparties sur 2 hôtes, soit $4 \div 2 = 2$ de plus chacun.

Charge finale par hôte : $4 + 2 = 6$ machines. La limite de 6 est atteinte exactement : elle est respectée, sans aucune marge.

Si un second hôte tombait, il resterait un seul hôte pour 12 machines, alors qu'il en accepte 6 au maximum : la moitié du parc ne pourrait pas être relancée.

Conséquence : on prévoit de la redondance, c'est-à-dire des capacités de réserve prévues à l'avance, et la virtualisation rend cette redondance plus facile à mettre en place.³

Au pire moment, un service est à 60 % et les deux autres à 15 % chacun : $60 + 15 + 15 = 90$ %.

Comme 90 % est inférieur à 100 %, l'hôte tient la charge, avec une marge de 10 points.

Si les pointes coïncidaient : $3 \times 60 = 180$ %, ce qui dépasse la capacité de l'hôte. Le regroupement ne fonctionnerait plus.

Ce raisonnement est la raison pour laquelle le regroupement est rentable seulement si les pointes de charge ne tombent pas systématiquement ensemble.³

Dans la pratique, on garde de la marge, car le fonctionnement virtualisé coûte lui-même des ressources.³

Besoin 1 : machine virtuelle. L'hôte est sous Linux, et un conteneur ne peut pas héberger un système différent de celui de l'hôte, par exemple Windows. Il faut donc une virtualisation complète.⁴

Besoin 2 : conteneurs. Le service tourne sous Linux comme l'hôte. Les conteneurs demandent moins de ressources qu'une virtualisation complète, car ils n'ont pas besoin d'émulation ni de machine intermédiaire : vingt copies sont donc plus légères.⁴

Besoin 3 : machine virtuelle. La virtualisation de système complet peut créer et restaurer des instantanés de l'état du système entier, ce qui répond à l'idée de revenir en arrière après une erreur.⁴

Dans une vraie salle, on peut combiner les deux : des machines virtuelles pour les cas où le système diffère de l'hôte, et des conteneurs pour multiplier rapidement des services légers.

Partie exacte : les conteneurs séparent des programmes, et cette séparation figure parmi les usages typiques de la conteneurisation pour améliorer la sécurité.⁴

Partie excessive : la sécurité apportée par un mécanisme de type chroot est loin d'être à toute épreuve. On ne peut donc pas parler d'isolation parfaite.⁴

De plus, tous les conteneurs reposent sur le même noyau, celui de l'hôte : une faiblesse de ce noyau touche potentiellement tous les conteneurs.

Mesures possibles : s'appuyer sur les mécanismes du noyau Linux, les espaces de noms pour isoler chaque conteneur et les groupes de contrôle (cgroups) pour limiter les ressources qu'il consomme, afin de réduire son effet sur les autres.⁴

Autre mesure : garder le système hôte à jour et prévoir de la redondance, car une défaillance de l'hôte touche tout ce qu'il porte.³