Je ne suis pas convaincu par ce concept, qui a aussi le défaut de ne pas permettre une liberté de déploiement. D'ailleurs en prétendant pouvoir supporter différentes distributions de Linux sur une même base Linux, les techniques de "paravirtualisation" deviennent nécessaires, avec pour conséquence de devoir modifier les installations des machines virtuelles installées, et de les lier assez fortement au système hôte.
Je ne suis pas non plus convaincu de la sécurité (elle peut être logicielle mais ne pas survivre à un crash d'un VM et pas sans effet non plus sur les autres VM). Le monde est plutôt parti sur la technologie des hyperviseurs, qui souffre de moins en moins des problèmes de performance passés, et permet beaucoup plus de contrôle par l'hyperviseur que par le micro-noyau utilisé dans le concept des containers, et qui n'offre pas assez de services ni de réelle sécurité, malgré l'isolation qu'ils sont sensés apporter. De plus cela impose des contraintes très fortes sur les possibilités de migration d'une machine virtuelle vers une autre avec un autre OS, puisqu'il sera très rarement possible de les migrer toutes en même temps. L'avantage en terme de performance ne va qu'en décroissant, les plateformes utilisées pour la virtualisation employant de plus en plus les processeurs modernes effectuant une virtualisation très sure au niveau du matériel, même sans utiliser aucune instruction privilégiée dans l'OS invité. Si instruction privilégiée il y a, ce n'est pas pour les OS invités mais pour l'hyperviseur lui-même, et ce sera le cas aussi dans le cas du micro-noyau supportant le principe du container. Reste alors à savoir s'il n'y a pas un juste milieu entre les deux approches, où une partie significative des services serait assurée par l'hyperviseur au lieu d'être répliquée dans chaque VM des OS invités. Là interviennent les techniques de paravirtualisation qui sont déjà très efficaces pour obtenir des performances élevées. Cela passe par des pilotes de périphérique installables de façon normale sur les OS invités, mais qui effectivement font des appels privilégiés à l'hyperviseur, qui d'abord s'assurera de conserver l'isolation et la sécurité, et du respect du partage des ressources entre les utilisations demandées par les OS invités dans leur VM. La paravirtualisation ne fonctionne en effet bien que si les invités sont à peu près homogènes dans leurs fonctions (mais on peut aussi dire que les OS diffèrent de moins en moins en ce qui concerne ce qu'ils supportent et demandent à leur plateforme hôte, car des tas de nomes sont passées par là, y compris le Plug-n-Play, le standard PCI, les bus utilisés dont les quasi-universels USB et Ethernet, les normes graphiques comme OpenGL) De fait, les trois techniques sont appelées à converger au point qu'on ne pourra plus les distinguer, permettant de la souplesse entre ce qu'on laisse faire dans chaque VM d'invité, et ce qu'on peut faire dans l"hyperviseur, fonctionnant aussi comme un OS classique, capable sans doûte dans le futur d'être lui-même virtualisé et remplaçable même à la volée sans que les VM invitées ne s'en aperçoivent (hormis peut-être juste une courte pause lors du déplacement, comparable à ce qu'aurait produit une mise en veille et les différentes techniques d'économie d'énergie qu'on trouve maintenant, le but à atteindre étant de ne presque plus jamais avoir à rebooter un OS invité, ni même l'hyperviseur ; on n'en est plus très loin, et ensuite on sera à l'ère du tout "cloud" extensible à l'infini aussi bien sur un réseau privé que chez des hébergeurs externes, et plus tard aussi sur des machines au départ inconnues ayant de la puissance de calcul immédiatement accessible à la demande pour du calcul distribué...). Le 25 février 2012 00:30, Christian Quest <cqu...@openstreetmap.fr> a écrit : > openvz n'est pas un hyperviseur au sens de VirtualBox, VMware ou autre > virtualiseur de hardware et peut donc difficilement leur être comparé. > > On utilise plutôt le terme de container à envisager comme un super > chroot qui ne se limite pas aux fichiers mais à tout ce qui touche au > kernel. > > C'est donc une virtualisation au niveau OS, qui permet d'être "root" > dans son container sans être root sur la machine et facilite > grandement la migration d'un serveur virtuel d'une machine à l'autre. > Un seul noyau linux (modifié) tourne sur la machine physique ce qui > permet une bien plus grande densité (nombre de VM exploitables pour un > même hardware) et une meilleure coordination de l'ensemble. > Par exemple, la RAM utilisée est vraiment minimisée car limitée aux > seuls besoin réels des process qui tournent et donc des applis. > > openvz ne nécessite donc aucune technologie additionnelle au niveau du > CPU pour être (à peut près) efficace. > > Sa principale (seule ?) limite est de n'offrir que de la > virtualisation linux/linux mais vu que l'immense majorité des > logiciels que nous utilisons sur nos serveurs viennent de ce monde, > cela n'est pas vraiment une limitation > > Pour plus d'info, vous pouvez consulter cette présentation au FOSDEM > 2012 au sujet d'openvz: > http://video.fosdem.org/2012/maintracks/janson/Linux_containers_and_OpenVZ.webm > > Et pour une version courte le wiki d'openvz: > http://wiki.openvz.org/Introduction_to_virtualization > > Ca m'évitera d'en faire un pseudo copier/coller. > -- > Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr