Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Bonjour, Tant que les garde-fous nécessaires sont là pour assurer la priorité matérielle et d'attention des administrateurs aux outils de contrôle qualité, aux scripts de stats purement liés à la base OSM, cela ne me gêne pas de voir des initiatives cousines hébergées. De la même manière que cela ne me perturbe pas plus que ça de voir ma Freebox servir de point d'accès pour les passants en bas de la rue, à la terrasse du café : ce n'est pas au détriment de la bande passante que j'ai achetée. Et jusqu'à preuve du contraire, ça ne devrait pas user ma Freebox outre mesure Une carte orientée biologie serait un bon exemple d'initiative cousine. D'un côté la base stockant les données carto serait distincte dans son contenu et ses objectifs de la base principale OSM De l'autre côté, sa structure et la chaîne de contribution / hébergement / usage pourrait suivre ce qui a été fait pour la base OSM. C'est également un bon moyen pour un courageux de creuser encore un peu plus le fonctionnement d'OSM en coulisses (l'API 0.6, Ruby on Rails, JOSM, Potlatch ...), en mode bac à sable. Le 24 février 2012 19:15, sly (sylvain letuffe) li...@letuffe.org a écrit : (...) N'étant pas membre de l'association, je ne me prononcerais pas sur le public visé et ceux pouvant en profiter, mais mon avis personnel et que les serveurs de l'asso devraient avant tout servir les contributeurs, mais ce n'est que mon avis. (...) Si je suis en stand-by, c'est que tout le problème est là, les machines actuelles sont vieillissantes et déjà pleines à craquer ou presque et il est difficile d'ajouter autre chose que des petits services pas trop perturbateurs. -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
+--On 24 février 2012 20:21:06 +0100 sly (sylvain letuffe) li...@letuffe.org wrote: | | Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un | hébergement n'attendaient plus qu'un OS et des développeurs faire | monter la charge :) | | Alors j'avoue que je ne me suis même pas posé la question, pour moi : | pas installé ça voulait dire : serveur dans ma cave en attente | d'une vrai maison | | Mais en effet, vu que ça donne le nom d'un hébergeur, ça vaut le coût | de savoir ce qu'il en ait vraiment, je vais donc poser la question à | Mat, en copie, qui est listé comme le mainteneur de ces 4 serveurs. Hum, non, des deux que j'ai, l'un fait serveur TRAPI comme indiqué, même si ça va certainement s'arrêter si osmarender s'arrête, l'autre, je l'ai installé en même temps, il n'a jamais servi mais il consomme du courant dans mes baies :-) Maintenant, ce sont des vieilles machines, qui consomment *beaucoup* de courant, et pas très évolutives, j'ai toujours dit que la deuxième machine, qui est en orange, peut faire qqchose si on me dit quoi, mais y'a 70Go de disque, ça va pas aller loin, et c'est du scsi, ça coute une blinde. -- Mathieu Arnold ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Salut, Hum, non, des deux que j'ai, l'un fait serveur TRAPI comme indiqué, même si ça va certainement s'arrêter si osmarender s'arrête, l'autre, je l'ai installé en même temps, il n'a jamais servi mais il consomme du courant dans mes baies :-) Merci pour ces précisions, j'ai mis à jour le wiki en conséquence. Je m'excuse si je ne me souviens plus trop, mais les mailings listes volent et les wiki restent ;-) Tu prévois quoi dans l'avenir ? Tu sembles insister sur le fait que ces 2 machines consomment trop, tu comptes plutôt les arréter ou il est possible de compte dessus encore pour un certain temps ? Est-il envisageable de les remplacer si on t'en fourni d'autres ? Quelqu'un d'autre que toi dispose-t-il du compte root sur la deuxième ? Peut- on avoir son IP/fqdn ? Quelles sont les contraintes/recommandation d'utilisation de la BP ? Maintenant, ce sont des vieilles machines, qui consomment *beaucoup* de courant, et pas très évolutives, j'ai toujours dit que la deuxième machine, qui est en orange, peut faire qqchose si on me dit quoi, mais y'a 70Go de disque, ça va pas aller loin, et c'est du scsi, ça coute une blinde. On a vu les réussites passées à tenter de les faire évoluer, je pense donc que c'est plus simple de les garder comme ça ou, si c'est possible, les remplacer. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Effectivement, les applis tournant autour d'OSM ont des besoins que peu d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il serait donc intéressant de pouvoir mutualiser des serveurs/services. Ce projet était à l'un des ordres du jour du groupe technique auquel j'ai participé et j'ai pas mal avancé sur ce projet dont les grandes lignes sont : - fournir des machines virtuelles socle sous virtualbox avec les outils nécessaires aux opérations de rendu, import de base osm ce qui permettrait de faire des tests/dev et éventuellement mise en place à long terme d'applications. Ces machines virtuelles tourneraient et pourraient aussi être dupliquée/téléchargées pour usage locale/ailleurs et auraient pour but de simplifier l'accès aux développeurs souhaitant mettre en oeuvre des outils. Mon premier prototype est prêt et je commence à maîtriser suffisamment virtualbox pour une mise en place. N'étant pas membre de l'association, je ne me prononcerais pas sur le public visé et ceux pouvant en profiter, mais mon avis personnel et que les serveurs de l'asso devraient avant tout servir les contributeurs, mais ce n'est que mon avis. En particulier, je me demandais s'il était possible d'occuper un peu d'espace sur le parcs de serveur dont dispose l'association [2]. Est-ce qu'une politique a déjà été définie au sein de l'association à ce sujet ? Si je suis en stand-by, c'est que tout le problème est là, les machines actuelles sont vieillissantes et déjà pleines à craquer ou presque et il est difficile d'ajouter autre chose que des petits services pas trop perturbateurs. Mais j'espère que christian va nous annoncer bientôt une bonne nouvelle concernant de nouvelles machines ;-) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Le vendredi 24 février 2012 à 19:15 +0100, sly (sylvain letuffe) a écrit : Effectivement, les applis tournant autour d'OSM ont des besoins que peu d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il serait donc intéressant de pouvoir mutualiser des serveurs/services. Ce projet était à l'un des ordres du jour du groupe technique auquel j'ai participé et j'ai pas mal avancé sur ce projet dont les grandes lignes sont : - fournir des machines virtuelles socle sous virtualbox avec les outils nécessaires aux opérations de rendu, import de base osm ce qui permettrait de faire des tests/dev et éventuellement mise en place à long terme d'applications. Ces machines virtuelles tourneraient et pourraient aussi être dupliquée/téléchargées pour usage locale/ailleurs et auraient pour but de simplifier l'accès aux développeurs souhaitant mettre en oeuvre des outils. Mon premier prototype est prêt et je commence à maîtriser suffisamment virtualbox pour une mise en place. Ok, bravo pour cet effort ! :) N'étant pas membre de l'association, je ne me prononcerais pas sur le public visé et ceux pouvant en profiter, mais mon avis personnel et que les serveurs de l'asso devraient avant tout servir les contributeurs, mais ce n'est que mon avis. En particulier, je me demandais s'il était possible d'occuper un peu d'espace sur le parcs de serveur dont dispose l'association [2]. Est-ce qu'une politique a déjà été définie au sein de l'association à ce sujet ? Si je suis en stand-by, c'est que tout le problème est là, les machines actuelles sont vieillissantes et déjà pleines à craquer ou presque et il est difficile d'ajouter autre chose que des petits services pas trop perturbateurs. Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un hébergement n'attendaient plus qu'un OS et des développeurs faire monter la charge :) Cela dit, je pense surtout à des petits services pas trop perturbateurs : maintenir à jour une (ou plusieurs) pyramides de tuiles à l'échelle de l'agglomération de Marseille. Si on considère que la base de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et qu'on s'en tient à une fréquence de mise à jour basse, alors la charge n'est pas colossale. Mais j'espère que christian va nous annoncer bientôt une bonne nouvelle concernant de nouvelles machines ;-) Attendons alors ! :) -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un hébergement n'attendaient plus qu'un OS et des développeurs faire monter la charge :) Alors j'avoue que je ne me suis même pas posé la question, pour moi : pas installé ça voulait dire : serveur dans ma cave en attente d'une vrai maison Mais en effet, vu que ça donne le nom d'un hébergeur, ça vaut le coût de savoir ce qu'il en ait vraiment, je vais donc poser la question à Mat, en copie, qui est listé comme le mainteneur de ces 4 serveurs. Cela dit, je pense surtout à des petits services pas trop perturbateurs : maintenir à jour une (ou plusieurs) pyramides de tuiles à l'échelle de l'agglomération de Marseille. En effet, ça devrait pas être la mort. Si j'ai bien compris les plans futurs, une nouvelle machine pourrait être mise en batterie pour faire des rendus, ce qui impliquera sans doute une base osm2pgsql france, ou même europe ou monde sur laquelle pourrons se greffer plein de projet de rendu spécifiques/test de plusieurs développeurs sans que l'on ait besoin de maintenir N bases de ce type. Si on considère que la base de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et qu'on s'en tient à une fréquence de mise à jour basse, alors la charge n'est pas colossale. Tout à fait, osm7 me semble avoir encore un peu de marge et je m'occupe de maintenir la base france à jour, mais j'ai cru comprendre que la BP disponible devrait être gardée basse et donc les tuiles ne sont pas forcément les bien venus, mais je pense que c'est surtout que si 1 mois après la mise en place on vous demande de déménager, c'est relou. A discuter sur t...@liste.openstreetmap.fr avec le chef de groupe Attendons alors ! :) Avec une dead line et solution de repli ;-) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Le 24 février 2012, sly (sylvain letuffe) a écrit : Ok. J'avais bêtement cru que les 4 serveurs qui sont en orange avec un hébergement n'attendaient plus qu'un OS et des développeurs faire monter la charge :) Alors j'avoue que je ne me suis même pas posé la question, pour moi : pas installé ça voulait dire : serveur dans ma cave en attente d'une vrai maison C'est bien le cas: tous les serveurs marqués pas installé sont rangés, et attendent un hébergement. À noter que ces machines n'ont pas beaucoup de disque dur de base, et qu'il faut faire des modifications si on veut plus de 100 Go. Si on considère que la base de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et qu'on s'en tient à une fréquence de mise à jour basse, alors la charge n'est pas colossale. Tout à fait, osm7 me semble avoir encore un peu de marge et je m'occupe de maintenir la base france à jour, mais j'ai cru comprendre que la BP disponible devrait être gardée basse et donc les tuiles ne sont pas forcément les bien venus, mais je pense que c'est surtout que si 1 mois après la mise en place on vous demande de déménager, c'est relou. Yep, osm7 et osm8 doivent garder une BP faible. Il est quand même possible d'y mettre des services qui ont besoin d'une base de donnée, tant que ce n'est pas du rendu de tuiles. Normalement, on devrait avoir des machines sous peu avec plus de bande passante - c'est juste le sous peu que je ne peux pas quantifier :) -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr (était : Re: Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes))
Le 24 février 2012 19:01, Gilles Bassière gbassi...@gmail.com a écrit : Le vendredi 24 février 2012 à 18:06 +0100, Ab_fab a écrit : Par contre, imaginons qu'une structure impliquée dans la géomatique libre et plus précisément OSM ait accès à _ un hébergement confortable _ des machines non moins confortables _ la possibilité d'y monter des machines virtuelles adaptées aux besoins des développeurs Elle pourrait mettre à disposition un espace pilote, permettant le défrichage technique pour ce type d'applications de niche. Si l'usage décolle et charge le système, la structure peut décréter que ses ressources matérielles n'ont pas pour vocation prioritaire d'héberger ce genre de projets périphériques à son coeur d'activité. Mais dans le même temps, c'est le signe que la masse critique sera atteinte pour aller ouvrir un serveur chez un hébergeur ou bien lancer un service commercial indépendant de prestation, aux coûts de fonctionnements mutualisés entre les utilisateurs Bref, même si cela sort du contexte pur et dur OSM, en tant qu'adhérent de l'asso osm-fr, je ne serais vraiment pas choqué que ce genre d'initiative soit mis en place sur les serveurs de l'asso. Effectivement, les applis tournant autour d'OSM ont des besoins que peu d'hébergements mutualisés peuvent satisfaire. Et tous les développeurs n'ont pas les moyens ou l'envie de louer et gérer un serveur dédié. Il serait donc intéressant de pouvoir mutualiser des serveurs/services. Lors de la rencontre entre mappeurs hier à Marseille [1], nous avons évoqués plusieurs idées dont la réalisation demanderait notamment : une réplique de la BD mise à jour automatiquement, de quoi générer des tuiles, un serveur Web, etc. Ces idées sont encore très floues (ce ne sont que des idées, pas encore des projets). Mais en y repensant, j'en suis quand même arrivé aux mêmes questions qu'Ab_fab. En particulier, je me demandais s'il était possible d'occuper un peu d'espace sur le parcs de serveur dont dispose l'association [2]. Est-ce qu'une politique a déjà été définie au sein de l'association à ce sujet ? [1] http://wiki.openstreetmap.org/wiki/Marseille/R%C3%A9unions_2012 [2] http://wiki.openstreetmap.org/wiki/FR:Servers Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ Bonsoir Gilles, L'association a aussi pour vocation de mettre en commun des ressources techniques. Nous avons déjà un ensemble de serveurs qui sont effectivement décrits sur http://wiki.openstreetmap.org/wiki/FR:Servers Nous devrions compléter ceux-ci très prochainement par plusieurs nouveaux serveurs, soit du même type, soit nettement plus puissants. La mise en commun permet aussi de se répartir les tâches ou de les mutualiser. Par exemple, sur osm7 une base France est disponible avec les 2 schémas osmosis et osm2pgsql. Ceci me permet sur le site web de faire des pages d'outil qui interrogent cette base, sans avoir à me préoccuper de la maintenance de cette base (merci Jocelyn et Fred). Nous avons une ML technique: t...@listes.openstreetmap.fr dispo sur http://listes.openstreetmap.fr/wws/info/tech -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Le sous peu dépend de Dell, en rupture de disque-durs... et de la signature d'une convention. Sinon, côté virtualisation, virtualbox c'est utile si on veut faire tourner du non-linux, sinon, il vaut mieux se tourner vers openvz, nettement plus efficace et économe en ressources. Si vous avez besoin d'aide pour vous lancer avec openvz, demandez-moi, je le pratique depuis déjà quelques temps. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
On vendredi 24 février 2012, Gilles Bassière wrote: Cela dit, je pense surtout à des petits services pas trop perturbateurs : maintenir à jour une (ou plusieurs) pyramides de tuiles à l'échelle de l'agglomération de Marseille. Si on considère que la base de données sous-jacente est mutualisée (osm7 si j'ai bien compris) et qu'on s'en tient à une fréquence de mise à jour basse, alors la charge n'est pas colossale. J'ai nettoyer cette page au karsher : http://wiki.openstreetmap.org/wiki/FR:Servers Il y a maintenant une place tout indiquée pour les projets a l'état d'idées (préparer le terrain afin d'éviter au dernier moment de se retrouver avec un refus) Et une place pour les projets à l'état de cherche maison -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
Le 24 février 2012 20:53, Christian Quest cqu...@openstreetmap.fr a écrit : Le sous peu dépend de Dell, en rupture de disque-durs... et de la signature d'une convention. Sinon, côté virtualisation, virtualbox c'est utile si on veut faire tourner du non-linux, sinon, il vaut mieux se tourner vers openvz, nettement plus efficace et économe en ressources. Peu importe, les machines virtuelles pour divers OS (pas que Windows ou Linux) peuvent normalement fonctionner sur différents types d'hyperviseurs, que ce soit VirtualBox, OpenVZ, ou des hyperviseurs commerciaux comme Windows Virtual Server ou VMware, et d'autres hyperviseurs maison gérés et fournis par les hébergeurs (selon ce qu'ils veulent facturer : espace disque, mémoire, CPU, bande passante, services de sauvegarde, systèmes redondants, avec ou sans mutualisation du matériel, sachant que les techniques actuelles évoluent en faveur de la mutualisation de matériels pour privilégier la redondance, le maintien du service et l'évolutivité d'échelle, la mutualisation n'étant pas un frein en terme de performance garantie, ni de faculté de déploiement sur des sites multiples suivant le principe très à la mode du cloud). Cependant, certains OS invités peuvent demander l'installation dans la machine virtuelle de certains pilotes spécifiques à l'hyperviseur, pour obtenir des performances acceptables ou certaines fonctions. En général cela concerne l'interface réseau virtuelle, le support d'une interface graphique 2D/3D avec de bonnes performances OpenGL ou la programmation native ultraparallélisée pour GPU, et quelques interfaces de supervision donnant accès à certaines fonctions de l'hyperviseur telles que le démarrage à distance, ou le déclenchement des sauvegardes dans un état stable. Ces pilotes spécifiques devraient normalement être plug-n-play et donc se désactiver tous seuls si on déplace une machine virtuelle vers un autre type d'hyperviseur ou sur une autre architecture (par exemple changement de technologie du processeur entre Intel et AMD, le contrôle de l'affectation des cœurs de CPU utilisés par l'OS invité). Ce n'est pas toujours le cas cependant car un OS a pu être installé avec le support d'APIC et ne pas supporter la transition vers un hyperviseur qui n'offre pas ce support (c'est le cas de Windows qui ne permet que la transition inverse, non réversible une fois qu'APIC a été activé dans l'OS invité, sinon ça plante complètement et c'est difficilement réparable). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
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
Re: [OSM-talk-fr] Utiliser les serveurs de l'asso osm-fr
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 lhyperviseur, 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
