[OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr

Philippe Verdy verdy_p at wanadoo.fr
Sam 25 Fév 01:36:20 UTC 2012


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 <cquest at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr




Plus d'informations sur la liste de diffusion Talk-fr