Principes fondamentaux de la

virtualisation
Abdelfattah TOULAOUI

1
QU’EST-CE QUE LA VIRTUALISATION ?
 Définition générale de la virtualisation
Définition (idée centrale) :
La virtualisation est une technique qui consiste à abstraire les ressources
physiques d’un système informatique afin de créer plusieurs
environnements logiques isolés, partageant le même matériel.
Autrement dit :
➔ Le matériel réel est masqué
➔ Chaque environnement voit une machine virtuelle complète
➔ Les ressources sont partagées, isolées et contrôlées
 La machine virtuelle (VM)
Une machine virtuelle est :
➔ Un environnement logiciel
➔ Qui se comporte comme une machine physique
➔ Avec :
◆ CPU virtuel
◆ Mémoire virtuelle
◆ Disques virtuels
◆ Cartes réseau virtuelles
➔ Exécutant son propre système d’exploitation
Pour l’OS invité, la VM est une vraie machine.
 Le rôle de l’hyperviseur
L’élément clé de la virtualisation :
Hyperviseur (ou VMM – Virtual Machine Monitor) :
➔ Couche logicielle entre le matériel et les VM
➔ Alloue et arbitre les ressources
➔ Garantit l’isolation
➔ Contrôle l’exécution des OS invités
👉 Sans hyperviseur, pas de virtualisation de type VM.
 Vue conceptuelle simplifiée
Le matériel est mutualisé, mais les OS restent isolés.
 Virtualisation vs émulation
⚠ Confusion fréquente
Émulation :
➔ Reproduit un matériel différent
➔ Instructions traduites une à une
➔ Très flexible mais lent
Virtualisation :
➔ Utilise le même type de CPU
➔ Instructions exécutées nativement (ou quasi)
➔ Performances proches du natif
👉 La virtualisation n’imite pas le matériel :
elle l’exploite.
 Transparence de la virtualisation
Propriété importante :
➔ L’OS invité n’a pas conscience (ou presque) d’être virtualisé
➔ Il fonctionne sans modification majeure
➔ Les applications s’exécutent normalement
On parle de transparence ou d’illusion de machine réelle.
 Virtualisation des ressources : vue détaillée
Chaque ressource est virtualisée séparément :
➔ CPU → vCPU, planification, time-sharing
➔ Mémoire → adresses virtuelles, mapping
➔ Stockage → disques virtuels, fichiers image
➔ Réseau → cartes réseau virtuelles, switches virtuels
La VM voit une machine cohérente, même si tout est abstrait.
 Isolation et sécurité : un point central
Grâce à la virtualisation :
➔ Une VM ne peut pas accéder à la mémoire d’une autre
➔ Une panne reste confinée
➔ Les environnements sont cloisonnés
👉 L’isolation est à la fois :
➔ une exigence de sécurité
➔ une exigence de stabilité
 Multi-tenant : plusieurs utilisateurs, un même matériel
La virtualisation permet :
➔ Plusieurs clients / services sur un même serveur
➔ Sans se faire confiance mutuellement
➔ Avec des quotas et des limites de ressources
C’est le fondement des environnements mutualisés modernes.
 Pourquoi la virtualisation est une rupture majeure
Avant :
➔ Infrastructure rigide
➔ Déploiements lents
➔ Dépendance au matériel
Après :
➔ Infrastructure logicielle
➔ Ressources dynamiques
➔ Mobilité des systèmes
👉 On passe du serveur physique à l’infrastructure programmable.
MOTIVATION ET CONTEXTE HISTORIQUE
DE LA VIRTUALISATION
 Avant la virtualisation : le modèle “un serveur = une
application”
Modèle dominant jusqu’aux années 1990–2000 :
➔ Un serveur physique dédié par application
➔ OS installé directement sur le matériel (bare metal)
➔ Configuration statique, longue à déployer
Problèmes majeurs :
➔ Faible taux d’utilisation CPU (souvent < 10–15 %)
➔ Coût élevé (achat, énergie, refroidissement)
➔ Faible flexibilité (migration, montée en charge)
➔ Dépendance forte au matériel
 Sous-utilisation chronique des ressources
Observation clé dans les data centers :
➔ CPU inactif la majorité du temps
➔ Mémoire rarement exploitée à plein
➔ Disques et réseau sous-chargés
Conséquence :
➔ Gaspillage massif de ressources
➔ Difficulté à justifier les coûts
➔ Explosion du nombre de serveurs physiques
👉 La virtualisation naît d’un problème économique et opérationnel, pas académique.
 Contraintes opérationnelles des infrastructures
physiques
Sans virtualisation :
➔ Déploiement lent (jours/semaines)
➔ Pannes = interruption complète du service
➔ Sauvegarde et reprise complexes
➔ Tests et environnements isolés coûteux
➔ Maintenance matérielle intrusive
Idée clé : le matériel impose son rythme au logiciel.
 Retour historique : les mainframes (années 1960–1970)
Ironiquement, la virtualisation n’est pas nouvelle :
➔ IBM introduit la virtualisation sur mainframes
➔ Objectif : partager un système coûteux entre plusieurs utilisateurs
➔ Machines virtuelles déjà présentes (VM/370)
Mais :
➔ Réservée aux grandes entreprises
➔ Disparition avec l’arrivée des serveurs x86 bon marché
 L’ère x86 : puissance croissante, gestion archaïque
Années 1990–2000 :
➔ Explosion des serveurs x86
➔ Puissance CPU augmente plus vite que les besoins logiciels
➔ Chaque application réclame “son” serveur
Résultat :
➔ Data centers surchargés
➔ Complexité de gestion exponentielle
➔ Faible agilité
👉 Le matériel progresse, mais le modèle d’exploitation ne suit pas.
 Problème fondamental : le couplage logiciel ↔ matériel
Sans virtualisation :
➔ OS dépend fortement du matériel
➔ Migration difficile voire impossible
➔ Tests non reproductibles
➔ Dépendance aux pilotes et au firmware
Question clé :
Peut-on découpler le logiciel du matériel ?
La virtualisation apporte une réponse claire : oui.
 Idée fondatrice de la virtualisation
Principe central :
Introduire une couche d’abstraction entre le matériel et les systèmes
d’exploitation
Cette couche :
➔ Présente un matériel virtuel standardisé
➔ Isole les environnements
➔ Permet le partage sécurisé des ressources
👉 Le matériel devient un pool de ressources, non plus une contrainte rigide.
HYPERVISEURS ET VIRTUAL MACHINE
MONITORS (VMM)
 Définition : hyperviseur / VMM
Hyperviseur (ou Virtual Machine Monitor – VMM) :
Logiciel (ou firmware) qui permet à plusieurs machines virtuelles de
s’exécuter simultanément sur un même matériel physique, tout en assurant
l’isolation, le partage et la gestion des ressources.
Les deux termes sont souvent utilisés comme synonymes.
 Responsabilités fondamentales de l’hyperviseur
L’hyperviseur doit :
➔ Planifier l’accès au CPU
➔ Allouer et protéger la mémoire
➔ Virtualiser les périphériques (I/O)
➔ Garantir l’isolation entre VM
➔ Gérer le cycle de vie des VM
👉 C’est un composant critique de sécurité et de stabilité.
 Isolation : responsabilité clé
Isolation assurée par l’hyperviseur :
➔ Une VM ne peut pas lire/écrire la mémoire d’une autre
➔ Une panne reste confinée
➔ Un OS invité compromis ne doit pas compromettre l’hôte
On parle souvent de barrière de confiance.
 Hyperviseurs de type 1 (bare-metal)
Définition :
➔ Installés directement sur le matériel
➔ Pas d’OS hôte généraliste en dessous
Caractéristiques :
➔ Performances élevées
➔ Surface d’attaque réduite
➔ Utilisés en production et data centers
 Avantages des hyperviseurs type 1
➔ Accès direct au matériel
➔ Faible overhead
➔ Meilleure isolation
➔ Haute disponibilité et scalabilité
👉 C’est le standard industriel pour les infrastructures virtualisées.
 Hyperviseurs de type 2 (hosted)
Définition :
➔ S’exécutent au-dessus d’un OS hôte
➔ L’hyperviseur est une application
Caractéristiques :
➔ Facilité d’installation
➔ Dépendance à l’OS hôte
➔ Overhead plus important
 Cas d’usage des hyperviseurs type 2
Adaptés pour :
➔ Environnements de test
➔ Formation et enseignement
➔ Développement local
➔ Démonstrations
Moins adaptés pour :
➔ Production critique
➔ Haute disponibilité
➔ Charges intensives
 Comparaison Type 1 vs Type 2
Type 1 :
➔ Performance
➔ Robustesse
➔ Production
Type 2 :
➔ Simplicité
➔ Flexibilité
➔ Usage personnel ou pédagogique
👉 Le choix dépend du contexte, pas de la
technologie seule.
 VMM : composant interne de l’hyperviseur
Le VMM :
➔ Gère une VM spécifique
➔ Intercepte les instructions sensibles
➔ Émule ou redirige vers le matériel
➔ Assure la cohérence de l’environnement virtuel
Un hyperviseur peut gérer plusieurs VMM simultanément.
 Instructions privilégiées et contrôle
Problème fondamental :
➔ Certains OS exécutent des instructions réservées au matériel
Solution :
➔ Le VMM intercepte ces instructions
➔ Les émule ou les exécute de façon contrôlée
👉 C’est un point clé pour la virtualisation CPU.
 Hyperviseur et performances
Défis principaux :
➔ Minimiser l’overhead
➔ Partager équitablement les ressources
➔ Éviter la famine (starvation)
➔ Maintenir une latence acceptable
Les hyperviseurs modernes s’appuient fortement sur le support matériel.
 Hyperviseur : composant de confiance
Dans un environnement virtualisé :
➔ L’hyperviseur est plus critique que l’OS invité
➔ Toute faille impacte potentiellement toutes les VM
👉 Principe clé : code minimal, privilèges maximaux
FONDAMENTAUX DE LA
VIRTUALISATION DU CPU
 Le défi fondamental du CPU
Problème central :
➔ Un processeur physique
➔ Plusieurs systèmes d’exploitation
➔ Chaque OS pense être seul maître du CPU
Mais :
➔ Un OS attend un accès exclusif
➔ Certaines instructions sont critiques
➔ Le CPU n’a qu’un seul état réel à la fois
👉 Il faut partager sans casser les règles.
 Rappel : modes d’exécution du CPU
Les processeurs modernes utilisent des niveaux de privilèges :
➔ Ring 0 : noyau (kernel)
➔ Ring 3 : applications utilisateur
Objectif :
➔ Protéger le système
➔ Empêcher une application de contrôler le matériel
Traditionnellement :
➔ Un seul OS occupe le Ring 0
 Problème en environnement virtualisé
Dans une VM :
➔ Chaque OS invité veut être en Ring 0
➔ Mais un seul Ring 0 physique existe
Conflit :
➔ Plusieurs OS ne peuvent pas être tous “kernel réel”
➔ Certaines instructions ne peuvent pas être exécutées librement
👉 C’est le problème historique de la virtualisation CPU.
 Instructions privilégiées
Certaines instructions :
➔ Modifient l’état du CPU
➔ Gèrent la mémoire
➔ Contrôlent les interruptions
➔ Accèdent aux périphériques
Exemples conceptuels :
➔ activer/désactiver interruptions
➔ modifier des registres de contrôle
👉 Ces instructions doivent être contrôlées par l’hyperviseur.
 Traps et interceptions
Mécanisme clé :
➔ Une instruction sensible est exécutée
➔ Le CPU déclenche un trap
➔ Le contrôle passe au VMM
Le VMM :
➔ Analyse l’instruction
➔ L’émule ou la redirige
➔ Met à jour l’état de la VM
👉 Le VMM devient l’arbitre de l’exécution.
 Approche 1 : virtualisation par traduction binaire
Méthode historique (avant support matériel) :
➔ Le VMM analyse le code de l’OS invité
➔ Remplace les instructions sensibles
➔ Injecte des appels contrôlés
Avantages :
➔ Fonctionne sans support matériel
Inconvénients :
➔ Complexe
➔ Overhead non négligeable
➔ Maintenance difficile
 Approche 2 : paravirtualisation
Principe :
➔ L’OS invité est modifié
➔ Il coopère avec l’hyperviseur
➔ Appels explicites (hypercalls)
Avantages :
➔ Meilleures performances
➔ Moins d’émulation
Inconvénients :
➔ OS non standard
➔ Nécessite modifications du noyau
 Limites des approches purement logicielles
Les deux approches précédentes :
➔ Ajoutent de la complexité
➔ Introduisent de l’overhead
➔ Dépendent fortement du logiciel
👉 L’industrie avait besoin d’une solution matérielle.
 Virtualisation assistée par matériel
Les processeurs modernes intègrent des extensions :
➔ Nouveau mode d’exécution pour les hyperviseurs
➔ Support natif des traps
➔ Séparation claire des contextes
Objectif :
➔ Simplifier le VMM
➔ Réduire l’overhead
➔ Améliorer la sécurité
 Nouveaux modes CPU pour la virtualisation
Avec support matériel :
➔ Mode hyperviseur
➔ OS invités exécutés sans modification
➔ Instructions sensibles automatiquement interceptées
Le CPU sait désormais :
➔ quand une instruction vient d’une VM
➔ quand elle doit être contrôlée
 Planification du CPU (CPU scheduling)
Le CPU physique est partagé via :
➔ Time-sharing
➔ Découpage en quanta de temps
➔ Attribution dynamique aux vCPU
Chaque VM dispose de :
➔ un ou plusieurs vCPU
➔ mappés dynamiquement sur le CPU réel
👉 Le CPU devient une ressource virtualisée.
 vCPU : abstraction du processeur
Un vCPU :
➔ N’est pas un cœur physique
➔ Représente une unité de calcul virtuelle
➔ Est planifié par l’hyperviseur
Conséquences :
➔ Sur-allocation possible
➔ Performance dépend du scheduling
➔ Concurrence entre VM
 Overcommitment CPU
Principe courant :
➔ Plus de vCPU que de cœurs physiques
Avantages :
➔ Meilleure utilisation moyenne
➔ Flexibilité
Risques :
➔ Contention
➔ Latence
➔ Dégradation sous charge
👉 Le dimensionnement est un compromis.
 Performance : proche du natif
Grâce au support matériel :
➔ La majorité des instructions s’exécutent directement
➔ Les traps sont rares
➔ L’overhead est faible
Dans de nombreux cas :
➔ performance ≈ natif
➔ surtout pour les workloads CPU-bound
VIRTUALISATION DE LA MÉMOIRE
 Le problème fondamental de la mémoire
Dans une machine classique :
➔ Un OS contrôle toute la mémoire physique
➔ Il gère :
◆ allocation
◆ protection
◆ pagination
Dans un environnement virtualisé :
➔ Plusieurs OS invités
➔ Chacun pense posséder toute la RAM
➔ Mais il n’existe qu’une seule mémoire physique réelle
👉 La mémoire doit être partagée sans confusion ni fuite.
 Rappel : virtual memory (sans virtualisation)
Dans un système non virtualisé :
➔ Les applications utilisent des adresses virtuelles
➔ Le noyau les traduit en adresses physiques
➔ La MMU (Memory Management Unit) applique cette traduction
Schéma classique :
Adresse virtuelle → Adresse physique
Objectifs :
➔ Isolation des processus
➔ Simplification de la programmation
➔ Utilisation efficace de la RAM
 Nouveaux niveaux d’adressage en virtualisation
Avec virtualisation, on ajoute une couche :
[Link] virtuelle (VA) → vue par les applications dans la VM
[Link] physique invitée (GPA) → vue par l’OS invité
[Link] physique réelle (HPA) → mémoire physique de la machine
👉 Il faut donc deux traductions, pas une.
 Traduction d’adresses : vue globale
Pipeline conceptuel :
VA (application)
→ GPA (OS invité)
→ HPA (hyperviseur / matériel)
Chaque étape doit garantir :
➔ isolation
➔ cohérence
➔ performance
 Rôle du VMM dans la mémoire
Le VMM doit :
➔ Contrôler quelles pages mémoire une VM peut utiliser
➔ Empêcher toute fuite entre VM
➔ Mapper dynamiquement la mémoire physique
➔ Gérer la pression mémoire globale
👉 La mémoire est une ressource critique et sensible.
 Shadow Page Tables (SPT)
Approche historique (logicielle) :
➔ L’OS invité maintient ses tables de pages
➔ Le VMM maintient une copie “shadow”
➔ Cette copie mappe directement :
◆ VA → HPA
Avantages :
➔ Fonctionne sans support matériel spécifique
Inconvénients :
➔ Complexité élevée
➔ Synchronisation coûteuse
➔ Overhead important lors des changements de pages
 Limites des Shadow Page Tables
Problèmes majeurs :
➔ Chaque modification de page par l’OS invité → intervention du VMM
➔ Forte pénalité de performance
➔ Implémentation complexe
👉 Comme pour le CPU, une solution matérielle était nécessaire.
 Virtualisation mémoire assistée par matériel
Les CPU modernes intègrent :
➔ EPT (Extended Page Tables) – Intel
➔ NPT (Nested Page Tables) – AMD
Principe :
➔ Le matériel gère les deux niveaux de traduction
➔ Le VMM fournit les tables GPA → HPA
➔ La MMU fait le reste
👉 La virtualisation devient transparente et efficace.
 Nested Paging : fonctionnement conceptuel
Avec nested paging :
VA → GPA (géré par l’OS invité)
GPA → HPA (géré par l’hyperviseur)
Avantages :
➔ Moins de traps vers le VMM
➔ Simplification du code hyperviseur
➔ Performances proches du natif
 Protection et isolation mémoire
Grâce à la virtualisation mémoire :
➔ Une VM ne peut accéder qu’à ses pages
➔ Les erreurs mémoire restent confinées
➔ Le VMM contrôle l’espace mémoire alloué
👉 L’isolation mémoire est fondamentale pour la sécurité.
 Allocation mémoire aux VM
Lors de la création d’une VM :
➔ Quantité de RAM définie (ex : 4 Go)
➔ Présentée comme mémoire physique complète
➔ En réalité :
◆ mappée dynamiquement sur la RAM réelle
La VM ignore totalement la concurrence avec les autres VM.
 Overcommitment mémoire
Principe :
➔ Allouer plus de mémoire virtuelle que de RAM physique
Pourquoi c’est possible :
➔ Toutes les VM n’utilisent pas leur mémoire max
➔ Statistiques d’usage favorables
Avantages :
➔ Meilleure densité
➔ Réduction des coûts
Risques :
➔ Pression mémoire
➔ Dégradation des performances
 Techniques d’optimisation mémoire
Les hyperviseurs utilisent :
➔ Ballooning
◆ le VMM récupère de la mémoire inutilisée
➔ Swapping
◆ pages déplacées vers le disque
➔ Page sharing
◆ pages identiques partagées entre VM
👉 Toujours un compromis performance ↔ densité.
 Ballooning : intuition
Fonctionnement :
➔ Un driver spécial dans la VM
➔ “gonfle” pour consommer de la mémoire
➔ Forçant l’OS invité à libérer des pages
Avantage :
➔ Coopératif
➔ Moins brutal que le swap
Limite :
➔ Dépend du comportement de l’OS invité
 Impact sur les performances
Facteurs clés :
➔ Accès mémoire plus fréquents que CPU
➔ Traductions supplémentaires
➔ Cache TLB sollicité
Avec support matériel :
➔ Overhead faible dans la majorité des cas
➔ Surtout perceptible sous forte pression mémoire
FONDAMENTAUX DE LA
VIRTUALISATION DES
ENTRÉES/SORTIES (I/O)
 Pourquoi la virtualisation I/O est complexe
Contrairement au CPU et à la mémoire :
➔ Les périphériques sont lents
➔ Très dépendants du matériel
➔ Génèrent des interruptions
➔ Ont des états complexes
👉 Virtualiser l’I/O est souvent le principal goulot d’étranglement.
 Rôle de l’hyperviseur pour l’I/O
L’hyperviseur doit :
➔ Présenter des périphériques virtuels aux VM
➔ Intercepter les accès matériels
➔ Arbitrer l’utilisation des périphériques physiques
➔ Garantir l’isolation entre VM
Objectif :
➔ Donner l’illusion d’un matériel dédié
➔ Sans compromettre la stabilité du système
 Types de périphériques virtualisés
On virtualise notamment :
➔ Stockage (disques)
➔ Réseau (cartes réseau)
➔ Entrées/sorties diverses (USB, GPU, etc.)
Chaque type pose des défis spécifiques en :
➔ performance
➔ latence
➔ sécurité
 Approche 1 : émulation de périphériques
Principe :
➔ L’hyperviseur émule un périphérique standard
➔ La VM utilise des pilotes génériques
➔ Pas de modification de l’OS invité
Avantages :
➔ Compatibilité maximale
➔ Fonctionne avec tout OS
Inconvénients :
➔ Overhead élevé
➔ Performances limitées
➔ Beaucoup de traps vers le VMM
 Quand l’émulation est utile
Cas typiques :
➔ OS anciens
➔ Compatibilité universelle
➔ Environnements de test
➔ Démarrage initial de VM
👉 C’est souvent la solution par défaut, mais rarement la plus performante.
 Approche 2 : paravirtualisation I/O
Principe :
➔ Périphériques virtuels optimisés
➔ Pilotes spécifiques dans l’OS invité
➔ Communication directe VM ↔ hyperviseur
Avantages :
➔ Meilleures performances
➔ Moins d’interruptions
➔ Moins d’overhead
Inconvénients :
➔ Nécessite pilotes adaptés
➔ Dépendance à l’hyperviseur
 Exemples de paravirtualisation
Périphériques typiques :
➔ Cartes réseau virtuelles optimisées
➔ Disques virtuels performants
Idée clé :
➔ Le périphérique est “fictif”
➔ Mais optimisé pour la virtualisation
👉 C’est le standard en production.
 Approche 3 : accès direct au matériel (passthrough)
Principe :
➔ Une VM accède directement à un périphérique physique
➔ L’hyperviseur délègue le contrôle
Avantages :
➔ Performances quasi natives
➔ Latence minimale
Inconvénients :
➔ Perte de flexibilité
➔ Moins de partage
➔ Isolation plus délicate
 Cas d’usage du passthrough
Adapté pour :
➔ GPU
➔ Cartes réseau haute performance
➔ Applications temps réel
➔ Calcul intensif
👉 Utilisé quand la performance est prioritaire sur la flexibilité.
 Comparaison des approches I/O
Émulation :
➔ Compatibilité
➔ Simplicité
➔ Performances faibles
Paravirtualisation :
➔ Bon compromis
➔ Performances élevées
➔ Standard industriel
Passthrough :
➔ Performances maximales
➔ Flexibilité réduite
 Interruptions et performances
Problème classique :
➔ Trop d’interruptions
➔ Surcharge CPU
➔ Latence accrue
Solutions modernes :
➔ Interruptions regroupées
➔ Files d’attente virtuelles
➔ Optimisations côté hyperviseur
 I/O virtuel et sécurité
Risques potentiels :
➔ Accès direct mal isolé
➔ Fuites entre VM
➔ Périphériques partagés mal contrôlés
Mesures :
➔ IOMMU
➔ Restrictions d’accès
➔ Validation stricte par l’hyperviseur
👉 La performance ne doit jamais casser l’isolation.
 I/O et virtualisation réseau
Cas particulier important :
➔ Réseau fortement sollicité
➔ Latence critique
➔ Scalabilité essentielle
On retrouve :
➔ cartes réseau virtuelles
➔ switches virtuels
➔ pare-feu logiciels
👉 Le réseau est souvent le premier I/O à optimiser.
 I/O et virtualisation du stockage
Pour le stockage :
➔ Disques virtuels = fichiers ou volumes
➔ Caches
➔ Files d’attente
➔ Snapshots
Impact direct sur :
➔ performances applicatives
➔ fiabilité
➔ sauvegardes
 Performance globale : compromis permanent
Choix I/O = compromis entre :
➔ performance
➔ compatibilité
➔ isolation
➔ flexibilité
👉 Il n’existe pas de solution universelle.
CONTAINERISATION : CONTINUITÉ
LOGIQUE DE LA VIRTUALISATION
 Pourquoi parler de containers ici ?
Constat :
➔ La virtualisation par VM fonctionne très bien
➔ Mais elle reste :
◆ lourde
◆ coûteuse en ressources
◆ parfois surdimensionnée
Question naturelle :
A-t-on vraiment besoin d’un OS complet par application ?
👉 La containerisation répond non.
 Idée centrale de la containerisation
Principe fondamental :
Isoler des applications au niveau du système d’exploitation, plutôt qu’au
niveau du matériel.
Autrement dit :
➔ Pas de matériel virtuel
➔ Pas d’OS invité complet
➔ Un kernel partagé
➔ Des environnements isolés
 Position des containers dans la pile
Comparaison conceptuelle :

👉 La couche “OS invité” disparaît.

 Container ≠ machine virtuelle
Un container n’est pas :
➔ une machine complète
➔ un OS indépendant
Un container est :
➔ un processus isolé
➔ exécuté par le noyau de l’hôte
➔ avec son propre environnement logique
 Réutilisation des mécanismes CPU vus
Containers et CPU :
➔ Utilisent le scheduler du noyau
➔ Partagent le CPU comme des processus classiques
➔ Isolation via :
◆ groupes de contrôle (quotas, priorités)
Lien direct avec :
➔ time-sharing
➔ sur-allocation
➔ scheduling
👉 Le CPU n’est pas virtualisé, il est partagé.
 Réutilisation des mécanismes mémoire vus
Containers et mémoire :
➔ Mémoire allouée dynamiquement
➔ Pas de GPA/HPA
➔ Pas de double traduction
Isolation mémoire via :
➔ espaces d’adressage distincts
➔ limites mémoire imposées par le noyau
👉 Plus simple et plus léger que la virtualisation mémoire VM.
 Réutilisation des mécanismes I/O vus
Containers et I/O :
➔ Accès indirect aux périphériques
➔ Virtualisation logique :
◆ interfaces réseau virtuelles
◆ systèmes de fichiers isolés
Performances :
➔ Proches du natif
➔ Peu d’overhead
👉 Les containers héritent de l’I/O de l’hôte.
 Isolation : comment c’est possible sans hyperviseur ?
Isolation assurée par le noyau :
➔ Espaces de noms (namespaces)
◆ processus
◆ réseau
◆ montage
◆ utilisateurs
➔ Limites de ressources (cgroups)
Chaque container voit :
➔ son propre “monde”
➔ sans voir les autres
 Namespaces : illusion d’environnement dédié
Grâce aux namespaces :
➔ PID isolés
➔ Interfaces réseau dédiées
➔ Arborescence de fichiers isolée
👉 Un container croit être seul, comme une VM.
 Cgroups : contrôle des ressources
Les cgroups permettent :
➔ Limiter le CPU
➔ Limiter la mémoire
➔ Contrôler l’I/O
Lien direct avec :
➔ overcommitment
➔ partage équitable
➔ isolation de charge
 Pourquoi les containers sont plus légers
Comparaison :
➔ Pas de kernel par container
➔ Pas de drivers
➔ Pas de boot OS
Résultat :
➔ Démarrage en millisecondes
➔ Très forte densité
➔ Faible empreinte mémoire
👉 C’est une virtualisation plus fine.
 Containers vs VM : synthèse conceptuelle
VM :
➔ Isolation forte
➔ OS complet
➔ Overhead plus élevé
Containers :
➔ Isolation plus légère
➔ Kernel partagé
➔ Très efficaces
👉 Ce sont deux outils complémentaires, pas concurrents.
 Containers et sécurité : limites
Points d’attention :
➔ Kernel partagé = surface d’attaque commune
➔ Isolation plus faible qu’une VM
➔ Dépendance à la configuration du noyau
Conséquence :
➔ Containers souvent exécutés dans des VM en cloud
 Containers comme brique du cloud moderne
Dans le cloud :
➔ VM = unité d’isolation forte
➔ Containers = unité d’exécution applicative
Empilement typique :
Matériel
Hyperviseur
VM
Containers
Applications
👉 On combine les deux mondes.
FIN