On entend de tout en ce qui concerne les performances des logiciels de virtualisation; difficile de savoir ce qui est sérieux.
J'ai donc profité de l'excellent cours de parallel computing and pthreads (EPFL), dans lequel je devais réaliser un mini-projet, pour faire un benchmark un tant soit peu sérieux. Pour rester dans le sujet du cours, je me suis focalisé sur des aspects liés au "HPC", à savoir les performances CPU, disque et communication.
Comme il fallait également choisir au niveau des logiciels, j'ai testé KVM, Xen, et VMware.
La machine, un vaillant Core2 Quad (mon ancien serveur de fichier/calcul), a travaillé sans relâche de la fin novembre à fin janvier.
Je profite donc de ce froid après-midi de février pour vous en partager brièvement ce que j'ai constaté:
- VMware n'est pas très adapté pour une application dont le réseau est primordial (MPI)
- Xen n'est pas très efficace pour les applications essentiellement limitées par le CPU
- KVM a un peu de la peine avec les accès disques en blocs
- ReiserFS avec VMware c'est suicidaire (cela fige la machine virtuelle)
La rapport ainsi les slides de la présentation, contenant entre autres la méthodologie, les résultats détaillés sont librement accessibles sur la page du projet (en anglais). Les fichiers de données, tous les scripts, ainsi que les fichiers LaTeX nécessaires pour créer les documents s'y trouvent également, sous licence libre (voir le fichier licenses.txt dans le SVN).
Je vais vraisemblablement pouvoir exécuter les benchmarks sur une machine beaucoup plus récente et puissante, et je ne manquerais pas de vous tenir au courant.
Par contre, cela m'intéresserait beaucoup de savoir si vos résultats et expériences vont dans le même sens que les miens (reproductibilité), ou si vous avec des remarques ou critiques concernant le rapport? (Il est déjà rendu, mais pour moi, il n'est jamais trop tard pour apprendre)
Merci et bonne lecture :-)
# licence vmware
Posté par Old Geek . Évalué à 5.
Pour info, si tu as oublié de lire la licence vmware, il est interdit
de publier des résultat de benchs sans leur approbation !
A+
Nicolas
[^] # Re: licence vmware
Posté par BlueWhisper . Évalué à 7. Dernière modification le 03 février 2012 à 17:34.
Dans la licence que j'ai acceptée, il est écrit:
J'ai donc utilisé VMware Workstation (sans installer X11, et en stoppant l'interface graphique) pour éviter le problème.
[^] # Re: licence vmware
Posté par Old Geek . Évalué à 4.
ok donc c'est bon !
[^] # Re: licence vmware
Posté par briaeros007 . Évalué à 6.
dommage, car chez vmware il faut plutôt utiliser les esx (esxi est dl gratuitement), les performances ont vraiment rien à voir qu'avec workstation (plusieurs centaines de VMs, avec un réseau beaucoup plus performants, voir même des switchs distribués).
Ce qui est payant chez vmware, c'est le "virtualcenter", cad la couche qui permet de gérer plusieurs hyperviseur, et qui gère aussi la couhe load balancing, migration des vms, ...
par contre, d'expérience, vmware peut avoir qq problèmes de "finitions" (voir des pertes de lun... il parait que c'est corrigé mais bon)
[^] # Re: licence vmware
Posté par dyno partouzeur de drouate . Évalué à 4.
Et bien tant mieux pour leur gueule si leur licence restrictive les dessert sur ce coup.
Si ça peut les faire changer d'avis...
[^] # Re: licence vmware
Posté par Guillaume Knispel . Évalué à 6.
En même temps où est-ce qu'une clause comme ça peut vraiment être valide ? Il me semble que l'étude en temps que blackbox d'un logiciel qu'on est autorisé à utiliser ne peut pas être interdit en France. Un benchmark relèverait probablement de ce cas. Qu'en est-il en Suisse ?
[^] # Re: licence vmware
Posté par JGO . Évalué à 1.
L'étude en boite noire est autorisée, c'est la publication des résultats qui est interdite par le contrat, qui comporte une clause d':fr:Accord de non-divulgation.
[^] # Re: licence vmware
Posté par Guillaume Knispel . Évalué à 3.
Je continue a ne pas être sûr de la possibilité d'exiger une telle confidentialité, du moins dans le cadre d'une licence contractable par le public sans filtrage ni négociation. Certes pris à la lettre L122-6 et L122-6-1 ne semblent pas interdire à l'auteur d'employer une telle limitation, mais je n'en suis pas complètement sûr et je me demande en outre s'il n'en est pas empêché par un autre moyen. De mon point de vue il faudrait demander à un spécialiste pour avoir un début d'avis plus éclairé.
[^] # Re: licence vmware
Posté par JGO . Évalué à 1.
C'est (ou c'était) aussi le cas pour MS SQL Server et Oracle Database, c'est aussi dans la licence de SAP. [C'est aussi une obligation pour les bêta-testeurs de tout un tas de logiciels (non-libres)]. Pourquoi cette clause serait-elle illégale uniquement pour vmware ?
[^] # Re: licence vmware
Posté par Guillaume Knispel . Évalué à 3.
Pas uniquement pour vmware. Pour tous. Ceci étant dit je suis bien conscient que je n'apporte aucun argument concret pour appuyer cette théorie.
[^] # Re: licence vmware
Posté par djnet . Évalué à 2.
Et la liberté de la presse on se la met ou ?
Interdiction de publier une information ...
C'est fou de mettre ça dans la licence.
# Et virtualbox?
Posté par weeber (site web personnel) . Évalué à 8.
Une idée des performances de VirtualBox par rapport aux autres?
Mon ressenti me dis qu'il est un peu plus rapide que VMware... mais ca n'a pas grande valeur ;)
[^] # Re: Et virtualbox?
Posté par kursus_hc . Évalué à 6.
Un avis sans grande valeur non plus : j'utilisais VMWare Player depuis des années (si je me souviens bien principalement à cause du mode fullscreen mieux intégré que ses concurrents), jusqu'à ce que je me décide à voir ailleurs (principalement à cause de la lassante chasse au patch à chaque changement de noyeau).
J'ai (re)testé VirtualBox et j'ai été extrêmement impressionné par ses performances (démarrage, extinction, consommation) par rapport à VMWare. Bon il faut dire aussi que mon usage est assez limité (browsers hostiles), mais j'ai rapidement changé de crèmerie. Et surtout il est intégré dans ma distribution!
[^] # Re: Et virtualbox?
Posté par claudex . Évalué à 4.
Il y a une grande différence entre utiliser une VM pour virtualiser un desktop et héberger des dizaines de VM sur un serveur pour héberger différent services. Je pense que c'est plutôt le deuxième cas qui est ciblé par cette étude et VirtualBox s'en sort très mal pour ça aux dernières nouvelles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et virtualbox?
Posté par B16F4RV4RD1N . Évalué à 3.
quel est donc le modèle économique de VirtualBox ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et virtualbox?
Posté par pasScott pasForstall . Évalué à 0.
Le meme que Java et OpenOffice: inexistant.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Et virtualbox?
Posté par weeber (site web personnel) . Évalué à 1.
Vu qu'il y a Oracle derrière, peut être qu'ils vendent du support pour les entreprises...
[^] # Re: Et virtualbox?
Posté par oinkoink_daotter . Évalué à 2.
En même temps, faire un benchmark sur ce genre de use cases avec VMware Workstation, c'est ptet pas non plus choisir le soft le plus adapté...
# quelques remarques
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Je serais curieux de voir les résultats avec Qemu, pour comparer.
Sinon, le rapport est intéressant.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
Posté par B16F4RV4RD1N . Évalué à 2.
facile, qemu sans kvm est extrêmement lent, vu que ce n'est que de la simple émulation de processeur, et non pas de la virtualisation.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: quelques remarques
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Non, ce n'est pas facile du tout. Seul les ios et ce qui concerne les opérations système sont lent. Le pure cpu n'est pas de raison d'être tellement plus lent.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
Posté par Kerro . Évalué à 3.
qemu émule CHAQUE instruction. Donc question lenteur c'est top.
Par contre ça permet de faire tourner du code ARM sur du x64 par exemple.
[^] # Re: quelques remarques
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Qemu fonctionne un peu moins connement que ça, heureusement.
Le code de qemu est composé de fonction C qui émule en effet chaque instruction de chaque CPU. Ces fonctions sont compilés avec un compilateur C. Ensuite, le header et le trailer de chaque fonction est enlevé. Lors de l'arrivé d'un code executable dans Qemu, chaque instruction est traduite par copie du coeur de la fonction de chaque instruction. Dans le cas d'instruction système, cela peut être gros. Dans le cas d'une traduction x86 vers x86, cela donne exactement la même instruction. La seul perte est donc dans la création à la volé du binaire correspondant, mais une fois dans une boucle, la vitesse est la même que la vitesse native.
C'est l'utilisation un peu détourné de gcc qui rendu difficile le passage de gcc 3.x à gcc 4.x.
"La première sécurité est la liberté"
# Variance des temps CPU pour Xen
Posté par zul (site web personnel) . Évalué à 1.
Tu as essayé de comprendre pourquoi les résultats en temps cpu des benchs Xen variaient autant (figure 1 en particulier) ? Voir plus loin pourquoi il était beaucoup plus mauvais ?
Quelle version de Xen utilises tu ?
Sinon, sur la forme, ce n'est pas forcément facile de bien comprendre tous les graphiques, certains sont normalisés, d'autres sont sous forme logarithmiques, certains sont du type "plus c'est haut, mieux c'est", d'autres l'inverse, d'autres n'ont pas tous les plateformes et comme il n'y a souvent qu'une toute petite légende sans explication du contexte, on ne sait pas trop ce que ça montre (un rappel du but / test de chaque benchmark serait sûrement un plus pour le lecteur de passage). De même, je ne suis pas sûr qu'indiquer le max plutôt que la moyenne soit forcément une bonne idée.
Enfin, sur le fond, il aurait sûrement été intéressant de savoir précisément pourquoi certains benchmarks étaient plus efficaces sur vm que sur le master (mais je ne sais pas si ça rentrait dans le temps du projet).
[^] # Re: Variance des temps CPU pour Xen
Posté par BlueWhisper . Évalué à 4.
Merci pour tes commentaires.
Je soupçonne que la grande variance et les mauvais résultats peut-être liée à des questions de scheduling de l'hyperviseur, mais je ne connais pas de moyens précis pour obtenir ces informations.
Celle fournie avec le kernel. Je n'ai pas sous la main le numéro de version des outils en userland, mais je ne crois pas que cela influence les résultats.
Concernant la présentation, c'est assez difficile de présenter de façon lisible des résultats qui peuvent être très différents, et le public visé est plutôt du type universitaire. J'avais également une contrainte de longueur de rapport, ce qui fait que j'ai dû être bref.
Pour l'instant la question a été mise de côté. C'est prévu d'étudier plus précisément ceci, si les résultats sont reproductibles avec du matériel plus moderne et avec des meilleures librairies plus optimisées (MKL).
# tester la virtualisation par conteneur
Posté par Dreammm . Évalué à -1.
Ce pourrait être également intéressant de comparer avec des solutions comme openVZ ou lxc, qui sont censées être plus proches des performances de bases de la machine réelle.
[^] # Re: tester la virtualisation par conteneur
Posté par fcartegnie . Évalué à 5.
Si c'est un conteneur, il n'y a pas de machine virtuelle...
# il manque des précisions
Posté par Christophe Turbout . Évalué à 2.
sympa comme tests mais il manque des infos.
Pour pouvoir faire quelque chose de reproductible, il faut donner aussi :
- toutes les versions des logiciels utilisés
- la version du noyau linux car entre les optimisations sur le FS et les modules de virtualisation du noyaux modifient les résultats.
- le type de container pour le FS ... de fait sur KVM par exemple si tu utilises du Qcow ou du Qcow2 tu n'as pas le même résultat
bon sinon, c'est une bonne base de travail pour se faire une idée ...
[^] # Re: il manque des précisions
Posté par BlueWhisper . Évalué à 2.
Lequel en particulier? Pour ce qui est du kernel, j'utilise le 3.1. Le reste est mentionné dans la figure 16.
J'utilise directement un partition disque. (C'est mentionné soit en annexe du rapport, soit dans les fichiers de configuration dans le SVN)
[^] # Re: il manque des précisions
Posté par goulou . Évalué à -1.
Et comme je ne suis pas allé cherché, et que je pense qu'il est intéressant que ce point figure ici : quelle mode as-tu utilisé? virtio, scsi, IDE?
Je pense comme les commentaires précédents sont pertinents, notamment pour la version du kernel et de Qemu/KVM : de mémoire, il y a eu des optimisations dans les 2 dernières versions (du kernel et de Qemu/KVM) justement relatives aux périphériques en mode bloc (donc les disques).
[^] # Re: il manque des précisions
Posté par BlueWhisper . Évalué à 1.
Je pense qu'avant de dire qu'il manque des précisions, il faut simplement lire le document! Je ne vais quand même pas le copier-coller dans le journal!
J'utilise virtio, j'ai (du moins tenté) de faire les choix pour avoir les meilleures performances possibles, tant sur l'hôte que dans la vm.
Les configurations du kernel sont dans le SVN, je vois pas vraiment ce que je peux faire de plus.
# Je suis novice dans le domaine
Posté par Laurent Mouillart . Évalué à 8.
Mais je pense qu'à utiliser Reiser c'est la mort.
[^] # Re: Je suis novice dans le domaine
Posté par B16F4RV4RD1N . Évalué à 5.
depuis quelques temps, les performances de ReiserFS sont enterrées.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Je suis novice dans le domaine
Posté par zerkman (site web personnel) . Évalué à 5.
Pourtant ça tuait bien sa mère (?) à une époque.
# NUMA et accès RAM
Posté par zerkman (site web personnel) . Évalué à 10.
Un problème majeur de la virtualisation est la fidélisation de la virtualisation de la topologie NUMA (Non Uniform Memory Access), permettant une utilisation efficace de la RAM.
La moindre machine bi-processeur à base d'i7 est NUMA (un banc mémoire par socket), et les AMD Opteron à 8 coeurs ou plus (Magny-Cours, Bulldozer ...) peuvent avoir 2 noeuds NUMA dans le même chip! Au boulot je travaille sur une machine Magny-cours à 4 sockets, et chaque proc est un Magny-cours à 12 coeurs (2 noeuds NUMA à 6 coeurs). Donc on a 8 noeuds NUMA sur la même machine, avec une topologie proche d'une arborescence. Les accès RAM entre 2 noeuds du même chip sont plus rapides qu'entre 2 noeuds sur des chips différents, par exemple.
On peut utiliser efficacement cette topologie en programmation multi-thread, grâce à des librairies comme Hardware Locality. Cela permet d'affecter des threads à des coeurs, d'allouer de la mémoire sur des noeuds NUMA choisis, etc, à partir d'informations très précises sur la topologie processeur et mémoire de la machine.
Tentative de virtualisation avec Xen : on se retrouve avec une topologie complètement plate, chaque coeur est vu comme un CPU indépendant des autres. Aucune info disponible non plus sur la taille des caches, sur quels procs partagent quels caches L3, etc. Résultat, les applis n'ont aucune info pour utiliser la RAM efficacement. D’ailleurs je pense que c'est la raison pour laquelle tu as une variation importante de tes résultats sur Xen. Tu peux tomber sur des cas où par chance, les accès mémoire se font de manière efficace, et d'autres non.
Sans parler de NUMA, un autre problème de Xen sur une machine qui fait de l'hyperthreading comme sur i7, tu n'as aucun moyen de savoir si 2 threads tournent sur 2 coeurs différents ou sur le même, chacun sur un thread hardware, car le noyau Linux n'a pas l'information. Si tes threads se retrouvent à tourner sur le même coeur, c'est foutu.
J'en suis arrivé à installer une Debian squeeze avec un noyau Vserver, ce qui me permet de travailler sur serveur invité en testing, avec une parfaite information sur la topologie NUMA, pour des perfs très proches d'un OS natif.
[^] # Re: NUMA et accès RAM
Posté par goulou . Évalué à 0.
libvirt/virt-manager avec Qemu (peut-être avec Xen) permet de définir la topologie NUMA.
Je ne suis pas expert du domaine, mais il y a plusieurs niveaux de granularité dans la configuration : de mémoire, thread/core/socket, ce qui correspond j'imagine à l'arborescence Hyperthreading/Coeurs/sockets. On peut ainsi par exemple affecter manuellement les N cœurs de la VM sur les cœurs 0, 1, 2, 3, ... de l’hôte, et indiquer à la VM que sa topologie est 2 threads*2coeurs : 4 CPU en hyperthreading sur 2 cœurs.
Je précise que je n'ai jamais essayé...
# Interessant
Posté par reno . Évalué à 4.
Il semble que le point faible principal de KVM soit les accès disques, ce qui est intéressant c'est que Xen fait mieux, comme les deux sont 100% opensources s'il y a quelqu'un de motivé pour comprendre la différence, ça doit être possible d'améliorer KVM ce qui en ferait une solution sans gros point faible (en tout cas pour un serveur, il y a aussi l'accélération vidéo/3D qui compte pour les desktop virtualisés).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.