Discussion :

[Pierre GIRARD]

Pour moi, le naïf, la question n'est pas :

• Isolateur
• Conteneur
• Hyperviseur

La question est, pour chacun de ces termes, ce que ça couvre. Mon esprit commence à s'ouvrir à tous ces concepts à force de suivre cette discussion, mais je me met à la place de celui qui va aux nouvelles pour la première fois. Avec des réponses trop techniques ou à l'inverse trop généralistes, je doute que ça soit compréhensible.

Ou alors, en cours de la FAQ, renvoyer vers un glossaire qui explicite chaque terme employé.

[Lana.Bauer]

Accès FAQ accordé à jlliagre.

[chrtophe]

Pierre,

Ou ne comprends tu pas ? (en dehors de l'histoire isolateur, conteneur, hyperviseur) . On va essayer de clarifier.

[Pierre GIRARD]

Pierre,

Ou ne comprends tu pas ? (en dehors de l'histoire isolateur, conteneur, hyperviseur). On va essayer de clarifier.

En dehors de : Isolateur, Conteneur, Hyperviseur ? déjà, si ces trois termes ne sont pas clairement définis, tout ce qu'il y aura derrière sera flou.

• Que fait un conteneur ?
• Que fait un superviseur ?
• Y-a-t-il aussi des conteneurs si il y a un superviseur ?
• Si un superviseur n'a pas besoin de conteneur : Pourquoi ?
• Quel sont les avantages de l'un par rapport à l'autre ?
• Qu'elles sont les restrictions des uns et des autres ?
• Pourquoi utiliser l'un plutôt que l'autre ? dans quels cas ? pour quoi faire ?
• etc...

Quelques fois, des petits schémas aident à comprendre où se situent les différences : au niveau matériel, au niveau logiciel (noyau ou au dessus) etc...

[jlliagre]

• Que fait un conteneur ?
  
  Un conteneur, c'est l'équivalent d'une machine virtuelle dans le cas de la virtualisation de système d'exploitation (SE). C'est une instance complète de SE, avec son système de fichiers, ses comptes utilisateurs, ses processus, etc. On peut s'y connecter et le rebooter. Tous les conteneurs instanciés au dessus d'un SE hôte partagent avec lui et entre eux un noyau unique.
  
  
• Que fait un hyperviseur ?(attention pas un superviseur)
  
  C'est le gestionnaire et l'ordonnanceur des machines virtuelles dans le cas de la virtualisation hardware. Un peu comme le noyau sait créer, exécuter et détruire des processus, un hyperviseur sait créer, exécuter et détruire des machines virtuelles.
  
  
• Y-a-t-il aussi des conteneurs si il y a un hyperviseur ?
  
  Pas forcément car les technologies ne sont pas liées. Il est cependant tout a fait possible de combiner ces deux techniques de virtualisation puisqu'elles se situent à des niveaux différents. Une machine virtuelle gérée par un hyperviseur peut donc elle même contenir des conteneurs.
  
  
• Si un hyperviseur n'a pas besoin de conteneur : Pourquoi ?
  
  Parce qu'il n'y a pas de lien entre les deux technologies.
  
  
• Quel sont les avantages de l'un par rapport à l'autre ?
  
  - La virtualisation à base de conteneurs est (beaucoup) moins gourmande en ressources et n'entraîne aucune dégradation de performances mesurable puisqu'il n'y a pas de couche additionnelle par rapport à un ordinateur traditionnel, sans virtualisation.
  
  - La virtualisation à base d'hyperviseur permet de choisir le système d'exploitation utilisé par les invités, qui n'a pas besoin d'avoir un lien fort avec celui de l'hôte.
  
  
• Qu'elles sont les restrictions des uns et des autres ?
  
  - La virtualisation à base de conteneurs limite les choix des SE des invités, les SE doivent être compatibles (linux sur linux, Solaris sur Solaris, AIX sur AIX, HP-UX sur HP-UX, etc.).
  
  - La virtualisation à base d'hyperviseur est plus gourmande en ressources et plus lente car il y a une couche de plus à exécuter (deux couches "système d'exploitation" sont empilées). La dégradation effective des performances varie suivant les opérations mesurées et la solution choisies.
  
  
• Pourquoi utiliser l'un plutôt que l'autre ?
  
  - Hyperviseur: Si OS incompatibles à instancier (exemple Windows et Linux). Si besoin d'avoir un vrai noyau (ex: développement de pilotes particuliers, de boot loader, tests de patches noyau, etc.). Si besoin de facilités particulières fournies par la solution retenue (live migration, interfaces d'administration et de gestion, etc .)
  
  - Conteneurs: permet de mettre beaucoup plus de systèmes virtualisés sur un environnement matériel donné. Plus de flexibilité dans la gestion et le partage des ressources. Solution forcément plus performante.
  
  
• dans quels cas ?
  
  cf . question précédente.
  
  
• pour quoi faire ?
  
  C'est vous qui voyez ... ;-)
  
  
• etc...

[Pierre GIRARD]

Voilà des réponses claires que j'aime bien, et en comprenant mieux on peut soi-même avancer certaines réponses à d'autres questions.

Par exemple, dans quels cas ?
Pour les Conteneurs, il semble évident que l'utilisation sera prioritairement pour des serveurs. Non seulement les SE "virtuels" ne prennent pas (ou peu) de ressources au SE "physique", mais en plus ils permettent même d'optimiser les ressources matérielles, vu que tous les SE n'ont aucune raison de travailler à 100% au même moment. Donc la mémoire, les processeurs et les disques seront mieux utilisés (limitant les investissements en matériel).

Pour des stations de travail individuelles, par contre, je ne vois pas grand intérêt à avoir plusieurs Linux ou plusieurs Windows sur la même station.

Sur mon PC, dual processeur, j'ai vu les physiquement les limitations en ressources. Si j'attribue 2 processeurs à une MV Windows et que la MV bosse à 100%, la machine hôte se trouve fortement ralentie. En ne donnant qu'un seul processeur à la MV, le ralentissement est beaucoup moins sensible sur la machine physique.

[chrtophe]

@jlliagre : bien répondu, rien à ajouter

@Pierre GIRARD : Virtualiser ou utiliser des conteneurs peut s'appliquer à des serveurs ou des machines individuelles. C'est vrai qu'il est plus utile d'utiliser des conteneurs sur un serveur. Exemple d'utilisation :tu place un serveur DNS dans un conteneur, un serveur DHCP dans un autre. Cela te permet d'isoler les services les uns des autres.

Virtualiser plusieurs systèmes sur une machine non serveur te permet de faire des tests, moi ça me sert à avoir plusieurs systèmes différents pour les mêmes raisons. Dans ce cas, je n'utilise pas les VMs de façon simultanée.

Je travailles sur Mac et PC. J'ai une VM Windows qui tourne en permanence sur mon Mac pour la bureautique.

Sur mon PC, dual processeur, j'ai vu les physiquement les limitations en ressources. Si j'attribue 2 processeurs à une MV Windows et que la MV bosse à 100%, la machine hôte se trouve fortement ralentie. En ne donnant qu'un seul processeur à la MV, le ralentissement est beaucoup moins sensible sur la machine physique.

C'est l’intérêt de bien dimensionner ses besoins. Pour des tests c'est pas très grave, pour de la prod c'est autre chose. Par contre l'intérêt aussi d'un système virtuel, c'est de pouvoir le déplacer sur une autre machine à config supérieure, c'est même faisable à chaud. (à condition d'avoir la fonctionnalité dans l'hyperviseur utilisé).

Pour hyperviseur type 2 type 3 tu as des shémas dans la réponse FAQ.

[Pierre GIRARD]

Virtualiser plusieurs systèmes sur une machine non serveur te permet de faire des tests

Pour ça, j'ai deux partitions identiques / et "/Sauv". Pour tester j'installe la Distribution sur /Sauv qui devient / pendant les tests (/ de la version précédente devenant /Sauv). Une simple modification dans Grub permet de passer de l'une à l'autre. Et pour moi, Windows est toujours dans une MV car une installation de Windows sur la machine physique casse Grub et tout ce qui va avec comme un sauvage.

C'est l’intérêt de bien dimensionner ses besoins. Pour des tests c'est pas très grave, pour de la prod c'est autre chose. Par contre l'intérêt aussi d'un système virtuel, c'est de pouvoir le déplacer sur une autre machine à config supérieure...

C'est bien ce que j'envisage pour l'avenir dans le but d'ajouter une MV Windows 7 ... 9 ... ? sans écrouler tout le système avec une MV en plus et tout en conservant mes MV actuelles.

[Lana.Bauer]

Salut,

On est arrivé à 55 questions, pour moi la FAQ est publiable.

Qu'en pensez-vous ?