Journal Comparaison des performances de machines virtuelles

27
3
fév.
2012

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 (page perso) . É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 . Évalué à  7 . Dernière modification : le 03/02/12 à 17:34

      Dans la licence que j'ai acceptée, il est écrit:

      2.4 Benchmarking.  You may use the Software to conduct internal
      performance testing and benchmarking studies, the results of
      which only You may publish or publicly disseminate, provided that
      VMware has reviewed and approved of the methodology, assumptions
      and other parameters of your testing and studies.  Please contact
      VMware at benchmark@vmware.com to request such review.  For VMware
      Workstation and Fusion benchmarks, You may publish or publicly
      disseminate the results without VMware’s prior review and approval.
      
      

      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 (page perso) . Évalué à  4 .

        ok donc c'est bon !

      • [^] # Re: licence vmware

        Posté par . É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 . É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 . É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 . É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 . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Et virtualbox?

          Posté par . Évalué à  3 .

          VirtualBox s'en sort très mal pour ça aux dernières nouvelles.

          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 . É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 . Évalué à  2 .

          Je pense que c'est plutôt le deuxième cas qui est ciblé par cette étude

          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 . Évalué à  7 .

    Je serais curieux de voir les résultats avec Qemu, pour comparer.

    Sinon, le rapport est intéressant.

    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

    • [^] # Re: quelques remarques

      Posté par . É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 . É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 liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

        • [^] # Re: quelques remarques

          Posté par . É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 . É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 liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

  • # Variance des temps CPU pour Xen

    Posté par (page perso) . É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 . Évalué à  4 .

      Merci pour tes commentaires.

      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 ?

      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.

      Quelle version de Xen utilises tu ?

      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.

      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).

      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 . É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.

  • # il manque des précisions

    Posté par . É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 . Évalué à  2 .

      toutes les versions des logiciels utilisés

      Lequel en particulier? Pour ce qui est du kernel, j'utilise le 3.1. Le reste est mentionné dans la figure 16.

      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

      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 . Évalué à  -1 .

        J'utilise directement un partition disque.

        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 . É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 . Évalué à  8 .

    Mais je pense qu'à utiliser Reiser c'est la mort.

  • # NUMA et accès RAM

    Posté par (page perso) . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.