Pour répondre juste à la partie finale: nous avons essayé de virtualiser même les conflits inter-VM (charge des processeurs) nous ont fait revenir en arrière.
De toute façon, mon expérience est que les coûts essentiels dans les archis serveurs
a) sont dans les RH et pas dans le hard: donc pas de réelle nécéssité d'optimiser les coûts HW au dernier centime (contrairement au mainframe...). Il est souvent plus efficace d'un point de vue financier global de mettre en place un serveur de plus que tenter de les empiler (avec les problèmes précités) dans une architecture virtualisée (VMware, Xen, etc...)
b) dans la gestion des OS (nombre d'images d'OS) que dans les boîtes: on passe beaucoup plus souvent des patches que l'on ne prend le tournevis pour changer qch au hw.
Donc, la virtualisation ne serait (toujours selon mon expérience perso...) qu'une optimisation du 2ème ordre. A admettre que ce soit vraiment une optimisation.
[^] # Re: Plateforme
Posté par Didier DURAND . En réponse à la dépêche Outils de transcodage COBOL vers Java du projet NACA publiés sous GPL/LGPL. Évalué à 8.
Pour répondre juste à la partie finale: nous avons essayé de virtualiser même les conflits inter-VM (charge des processeurs) nous ont fait revenir en arrière.
De toute façon, mon expérience est que les coûts essentiels dans les archis serveurs
a) sont dans les RH et pas dans le hard: donc pas de réelle nécéssité d'optimiser les coûts HW au dernier centime (contrairement au mainframe...). Il est souvent plus efficace d'un point de vue financier global de mettre en place un serveur de plus que tenter de les empiler (avec les problèmes précités) dans une architecture virtualisée (VMware, Xen, etc...)
b) dans la gestion des OS (nombre d'images d'OS) que dans les boîtes: on passe beaucoup plus souvent des patches que l'on ne prend le tournevis pour changer qch au hw.
Donc, la virtualisation ne serait (toujours selon mon expérience perso...) qu'une optimisation du 2ème ordre. A admettre que ce soit vraiment une optimisation.
Cordialement
didier