La machine virtuelle est-elle plus lente que la machine physique sous-jacente?

Cette question est assez générale, mais plus précisément, j'aimerais savoir si une machine virtuelle exécutant Ubuntu Enterprise Cloud sera plus lente que la même machine physique sans aucune virtualisation. Combien (1%, 5%, 10%)?

Quelqu'un a-t-il mesuré les différences de performances entre un serveur Web ou un serveur de base de données (physique virtuel VS)?

Si cela dépend de la configuration, imaginons deux processeurs quad-core, 12 Go de mémoire et un tas de disques SSD, exécutant un serveur d'entreprise ubuntu 64 bits. De plus, une seule machine virtuelle est autorisée à utiliser toutes les ressources disponibles.

L’expérience typique d’un workload de serveur général sur un hyperviseur nu \ Type 1 est d’environ 1 à 5% de la surcharge du processeur et de 5 à 10% de la mémoire, avec une surcharge supplémentaire qui varie en fonction de la charge globale des entrées / sorties. C'est assez cohérent dans mon expérience pour les OS invités modernes fonctionnant sous VMware ESX \ ESXi, Microsoft Hyper-V et Xen où le matériel sous-jacent a été conçu de manière appropriée. Pour les systèmes d'exploitation serveur 64 bits fonctionnant sur un matériel prenant en charge les extensions de virtualisation matérielle cpu les plus récentes, je m'attendrais à ce que tous les hyperviseurs de type 1 se dirigent vers ce nombre de frais supplémentaires de 1%. La maturité de KVM n’est pas tout à fait à la hauteur de Xen (ou de VMware) à ce stade, mais je ne vois aucune raison de penser que ce serait nettement pire qu’eux pour l’exemple que vous décrivez.

Pour des cas d'utilisation spécifiques, les "performances" globales \ agrégées d'un environnement virtuel peuvent toutefois dépasser les serveurs sans système d'exploitation \ discrets. Voici un exemple de discussion sur la manière dont une implémentation VMware Cluster peut être plus rapide \ meilleur \ moins cher qu'un Oracle RAC sans système d'exploitation. Les techniques de gestion de la mémoire de VMware (notamment le partage de page transparent) peuvent éliminer presque totalement la surcharge de mémoire si vous avez suffisamment de machines virtuelles suffisamment similaires. Dans tous ces cas, l’important est que les avantages en termes de performance et d’efficacité que la virtualisation peut offrir ne se concrétiseront que si vous consolidez plusieurs ordinateurs virtuels sur des hôtes. Votre exemple (un ordinateur virtuel sur l’hôte) sera toujours plus lent que le «bare metal» dans une certaine mesure. .

Bien que cela soit utile, les problèmes réels en termes de virtualisation de serveur sont généralement centrés sur la gestion, les techniques de haute disponibilité et l’évolutivité. Une marge de performance du processeur de 2 à 5% n’est pas aussi importante que de pouvoir s’adapter efficacement à 20, 40 ou le nombre de VM dont vous avez besoin sur chaque hôte. Vous pouvez faire face à la baisse des performances en sélectionnant un processeur légèrement plus rapide comme base ou en ajoutant plus de nœuds dans vos clusters, mais si l'hôte ne peut pas augmenter le nombre de machines virtuelles qu'il peut exécuter, ou si l'environnement est difficile à gérer ou non fiable alors sa valeur nulle du point de vue de la virtualisation de serveur.

"Performance" a de nombreux aspects. Le n00bs mesure le temps de démarrage d’un système d’exploitation et indique, par exemple, que Windows 2012 est vraiment génial, car il démarre en 12 secondes sur du HD réel, voire 1 seconde sur un SSD.
Mais ce type de mesure n’est pas très utile: les performances sont égales au temps de démarrage du système d’exploitation, mais celui-ci s’amorce une fois par mois, de sorte que l’optimisation n’a pas beaucoup de sens.

Parce que c’est mon travail quotidien, je pourrais souligner les 4 parties suivantes qui constituent la "performance"

1. Charge de l'unité centrale
   Cela devrait être comparable, ce qui signifie qu'une tâche prenant 1 000 ms sur du métal nu s'exécutera en 1 000 ms et probablement 1050 ms d'horloge dans un environnement de machine virtuelle inoccupée sur le même matériel (quelques détails ultérieurement). Google le MSDN pour processtime et queryperformancecounter et vous pouvez faire une chose qui peut montrer combien la VM mange votre temps de calcul.

2. Performance SQL
   Les performances SQL dépendent fortement des E / S vers le magasin de données dans lequel les données SQL sont stockées. J'ai constaté une différence de 300% entre la première génération ISCSI que vous pouvez trouver sur le NAS domestique de Buffalo, puis l'ISCSI avec DCE et un véritable environnement de vieille école FC, à tous les niveaux. Le FC gagne toujours de nos jours, car la latence du FC est le plus faible des objectifs pouvant conduire à une "copie" du protocole FC pour les améliorations du centre de données TCP / IP. Ici, les E / S et la latence sont essentielles, mais la bande passante E / S du processus serveur au média dépend également de l'application, selon que l'application a tendance à utiliser la technologie No-SQL ou Datawarehousing ou est au milieu de cela, comme les systèmes ERP ... Sage KHK pour les petites entreprises, SAP pour les énormes.

3. Accès au système de fichiers
   Certaines applications, telles que la diffusion vidéo en continu, reposent sur une bande passante minimale garantie, d’autres sur le débit maximal d’IO, comme l’ouverture de gros fichiers dans un éditeur hexadécimal, le chargement d’un projet vidéo dans votre prog. Ce n'est pas une situation typique sur une machine virtuelle ... les IOps peuvent également être importants pour les développeurs. Les développeurs utilisent souvent des ordinateurs virtuels car les environnements de développement sont très sensibles et la tentation de le faire dans un ordinateur virtuel est forte. Compiler un projet volumineux signifie souvent lire des tonnes de petits fichiers, faire le travail du compilateur et construire un fichier EXE et les composants correspondants.

4. Latence du réseau vers le client
   Ici, les progs WYSIWIG tels que Word 2010, Openoffice Writer, LaTEX, GSView et d’autres utilisent de manière extrêmement fiable la vitesse - la rapidité avec laquelle une souris passe du client au serveur. En particulier dans les applications de CAO, cela est important… mais ce n’est pas un problème de réseau local, c’est un accès à distance via le réseau étendu où cela est important.

Mais - et je parle du point de vue des années de consultation - il y a des utilisateurs qui ont le mot de passe administrateur (et ils sont souvent employés par une grosse entreprise avec un gros budget et un gros portefeuille) se plaignant de ceci et de cela, mais il faut clarifier quel élément de performance est important pour eux et important du point de vue de l'application utilisée.
Ce n'est probablement pas le bloc-notes, mais une application très sophistiquée pour l'ingénierie de ceci et de cela, qui coûte très cher et doit être déplacée sur VMware, HyperV ou Xenapp et ne fonctionne pas comme prévu.

Mais ils ne pensent pas qu'il peut fonctionner sur des serveurs Xeon de 1,5 GHz mais sur des serveurs non conçus pour les performances d'un processeur, ils sont conçus pour une moyenne, "optimisée pour $ par cycle de processeur" ou "cycles de processeur par Watt". .

Et lorsque nous parlons de compromis et d'économisations, cela conduit généralement à des surengagements. Les excès d’engagements entraînent un manque de ressources lorsque le processeur peut être assez bien géré, mais le manque de mémoire entraîne la pagination, le manque d’IO dans les principaux routeurs augmente les temps de réponse de tous, et une surcharge transactionnelle sur tout type de stockage peut bloquer toute application utile. de répondre trop rapidement. Dans ce cas, la surveillance est requise, mais de nombreux éditeurs de logiciels ne sont pas en mesure de fournir de telles informations .... par contre, un hôte avec des ressources de 3 serveurs physiques peut très probablement gérer 8 machines virtuelles de la même présentation, comme les physiques.

Les compromis de processeur sur les systèmes inactifs entraînent souvent des systèmes dont la performance est 50% plus lente que les systèmes physiques. Par contre, personne ne peut installer le système d'exploitation "réel" ni l'application "réelle" que les responsables informatiques du client souhaitent migrer vers la machine virtuelle. boîte. Et cela prend des jours (peut-être des semaines mais certainement 42 réunions) pour préciser que la technologie des machines virtuelles peut offrir une flexibilité en échangeant une vitesse de processeur pure. Ceci est simplement intégré dans les CPU de ces systèmes lames hébergeant de nos jours des environnements de VM plus grands. De plus, la mémoire ne sera pas comparable, certains compromis sont également applicables. La DDR3 1600 CL10 disposera d'une bande passante mémoire supérieure à celle du DDR2 800 ECC LLR - et tout le monde sait que les processeurs Intel en profitent différemment des processeurs AMD. Mais ils sont rarement utilisés dans des environnements productifs, plus dans les boîtes blanches ou dans les centres de données hébergés dans les pays du tiers monde qui offrent un service de centre de données pour 10% du prix, un centre de données de votre propre pays peut facturer votre facture. Grâce à Citrx, un centre de données peut être partout s'il a moins de 150 ms de temps de latence entre l'utilisateur final et le centre de données.

Et la perspective des utilisateurs à domicile ....

Enfin et surtout, certaines personnes veulent jeter Win7 ou XP et l'échanger contre Linux, puis la question du jeu se pose car en réalité, seuls quelques jeux sont disponibles pour Linux et Windows. Le jeu repose en grande partie sur l'accélération 3D. VMWare 6.5 Workstation et le lecteur libre connecté peuvent gérer DirectX 9, ce qui signifie qu'un serveur Doom3 d'une machine virtuelle peut s'exécuter en plein écran sur la carte graphique de l'hôte. Les jeux sont pour la plupart des applications 32 bits, ils ne consomment donc pas plus de 3 Go et pas plus de 3 processeurs (visibles sur Crysis). Les nouveaux lecteurs de machines virtuelles et WS peuvent gérer des versions DirectX supérieures et probablement OpenGL également. J'ai joué à UT et UT2004 sur VMware 6.5, l'hôte disposait d'un mobile ATI Radeon 2600 et d'un processeur T5440. Il était stable à 1280x800 et jouable même sur les jeux en réseau ....

Oui. Mais ce n'est pas la question. La différence est normalement négative (1% à 5%).

Je tiens à souligner que la virtualisation peut dépasser les performances physiques dans certaines situations. Étant donné que la couche réseau n'est pas limitée à la vitesse gigabit (même si l'émulation matérielle concerne une carte réseau spécifique), les ordinateurs virtuels situés sur le même serveur peuvent communiquer entre eux à des vitesses supérieures à celles de plusieurs serveurs phyiscaux dotés d'un équipement réseau moyen.

Je faisais quelques comparaisons de test du même logiciel exécutant le même test (application Web basée sur .NET avec un volume élevé de trafic Web et un accès considérable à SQL Server). Voici ce que j'ai vu:

• La machine physique est plus apte à instancier des classes (ce qui se traduit par l'allocation de mémoire au niveau du système) - cela me semble logique, car les machines physiques le font via un matériel de gestion de la mémoire et les machines virtuelles via un logiciel (avec une assistance matérielle partielle) (Sur la machine virtuelle , l'application a passé beaucoup de temps dans ses constructeurs (où la mémoire est allouée (et rien d'autre n'est fait), sur la machine physique, les constructeurs n'étaient même pas inclus dans le top 1000)
• Lorsque vous êtes au milieu d'une méthode, les deux sont à peu près équivalentes - c'est probablement ainsi que sont construits la plupart des points de repère montrant que les deux sont "identiques"
• Lorsque vous accédez à un contrôleur de réseau, le physique bat un peu la machine virtuelle - encore une fois, le physique n'a pas grand chose à faire entre le processus .NET et le matériel. VM ajoute d'autres "éléments" que chaque transaction doit parcourir.
• En réalité, la même chose s’applique à l’accès au disque (SQL Server était sur une autre machine) - la différence est très petite, mais lorsque vous les additionnez toutes, elles sont perceptibles. Cela peut être dû à un accès réseau plus lent ou à un accès disque plus lent.

Je peux facilement voir comment quelqu'un pourrait créer des points de référence prouvant qu'il est différent de 1% ou identique ou que les machines virtuelles sont plus rapides. N'incluez rien dans lequel votre processus tire parti des avantages du support matériel local, car la machine virtuelle doit la simuler dans un logiciel.

Vous essayez de comparer un système d'exploitation, un logiciel et des données installés sur un certain matériel physique avec les mêmes système d'exploitation, logiciels et données installés par lui-même dans un hyperviseur sur le même matériel d'origine. Cette comparaison n’est tout simplement pas valide, car presque personne ne le fait (du moins au début). Bien sûr, cela serait probablement plus lent. Heureusement, le point le plus fréquent de la virtualisation des serveurs est complètement omis.

Un meilleur exemple est de regarder deux (ou plus!) Serveurs plus anciens dans votre centre de données. Recherchez les serveurs qui fonctionnent assez bien, mais qui sont vieux et qui commencent à être actualisés. Ces serveurs fonctionnent déjà bien sur du matériel ancien, et donc, grâce à la loi de Moore, tout ce que vous obtenez de nouveau va être largement dépassé.

Donc que fais-tu? C'est simple. Plutôt que d'acheter deux nouveaux serveurs, vous n'en achetez qu'un, puis vous migrez vos deux anciens serveurs vers le même nouveau périphérique physique. Lorsque vous vous apprêtez à acheter votre nouveau serveur, vous prévoyez de disposer de suffisamment de capacité pour gérer non seulement la charge des deux serveurs plus anciens, mais également celle de l’hyperviseur (et peut-être un peu plus, de sorte que vous puissiez toujours bénéficier d’une amélioration des performances et de la performance. peut permettre la croissance).

En résumé: les machines virtuelles offrent des performances "assez bonnes" dans la plupart des situations et vous aident à mieux utiliser vos serveurs pour éviter les pertes de puissance de calcul.

Maintenant, étendons cela un peu plus loin. Étant donné qu’il s’agit de vieux serveurs, vous envisagiez peut-être de remplacer quelques serveurs de boîtes à pizza à 1 500 dollars. Il est fort probable que même une de ces boîtes à pizza puisse facilement supporter le fardeau des deux machines hypothétiques plus anciennes ... mais supposons que vous décidiez de dépenser 7 500 dollars ou plus sur du matériel réel à la place. Maintenant, vous avez un appareil qui peut facilement gérer jusqu'à une douzaine de vos serveurs existants (en fonction de la manière dont vous gérez le stockage et la mise en réseau), avec un coût initial de seulement 5. Vous bénéficiez également des avantages de la gestion d'un seul serveur physique, du découplage votre logiciel à partir de votre matériel (c'est-à-dire que l'actualisation du matériel nécessite moins de nouvelle licence Windows ou de temps d'arrêt), vous économisez une tonne d'énergie et votre hyperviseur peut vous fournir des informations plus performantes que vous ' J'ai eu dans le passé. Obtenez-en deux et, en fonction de votre taille, votre centre de données entier ne compte plus que deux machines, ou vous souhaitez peut-être utiliser le second serveur comme serveur de secours à chaud pour raconter une meilleure histoire de haute disponibilité.

Ce que je veux dire ici, c'est qu'il ne s'agit pas uniquement de performance. Je ne prendrais jamais un serveur de production parfaitement bon et ne le virtualiserais qu’à un matériel équivalent, tout simplement. Il s'agit davantage d'économies de coûts et d'autres avantages que vous pouvez tirer de la consolidation, tels que la haute disponibilité. En tirant parti de ces avantages, vous déplacez des serveurs vers différents matériels, ce qui signifie que vous devez prendre le temps nécessaire pour dimensionner correctement ces matériels, y compris en prenant en compte la pénalité d'hyperviseur. Oui, vous aurez peut-être besoin d'un peu plus de puissance de calcul au total que si chacune de ces machines disposait de son propre périphérique physique (astuce: vous avez probablement besoin de beaucoup moins de puissance de calcul totale ), mais cela coûtera beaucoup moins cher et consomme moins d'énergie. et plus facile à maintenir pour exécuter un serveur physique que pour plusieurs.

Je viens de passer à un SSD (OCZ Vertex 2) et j'exécute mon environnement de développement XP VM, je suis un développeur de logiciels. Une chose que j’ai remarquée, c’est que lorsque je lance un programme (un programme assez volumineux pour prendre du temps à se charger), un noyau de la CPU virtuelle se détache. Cela se produit lors du chargement d'IE également. Étant donné que le processeur est en place, je suppose que le goulot d'étranglement est le processeur et non le SSD. Mais cela semble étrange, j’ai le sentiment que si la même chose se produisait sur une machine physique, elle se chargerait plus rapidement et j’ai le sentiment que la surcharge de traitement occasionnée par VMWare consomme de la CPU sur l’accès au disque.

Par exemple, j'utilise Delphi et sur une machine physique avec un disque dur classique, le démarrage peut prendre 20 secondes à partir d'un démarrage à froid. Sur la VM exécutant un SSD, celle-ci se charge 19 secondes après un démarrage à froid. Pas beaucoup de différence, je parie que si le SSD était sur la machine physique, il se chargerait plus rapidement. Cependant, je n’ai pas vérifié l’utilisation du processeur sur la machine physique, c’est aussi possible que le processeur soit le goulot d’étranglement.

Mais l'impression de la machine virtuelle est que l'accès au disque impose des taxes à la machine virtuelle.

De toute évidence, une machine virtuelle est plus lente que la machine physique. Mais lorsque vous êtes dans ce scénario, vous devez évaluer ce qui est optimal pour couvrir vos besoins. Si vous n'avez besoin que d'un seul système et que vous souhaitez qu'il soit rapide, installez-le directement sur le matériel. D'autre part, si vous avez besoin de flexibilité, d'évolutivité (et de tous les autres avantages de la virtualisation: P), déployez une machine virtuelle. Ce sera plus lent, mais à mon humble avis, dans certains cas, cela est justifié et la performance n’est pas très lente.

Il semble que Microsoft ait effectué des tests d'évaluation à l'aide de serveurs BizTalk et SQL Server dans différentes configurations à cet égard. Voir le lien ci-dessous:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

Idéalement, les performances de Virtual PC sont à:

CPU: 96-97% de l'hôte

Réseau: 70 à 90% de l'hôte

Disque: 40-70% de l'hôte

Désolé de ne pas être d'accord avec TomTom.

J'utilise VMware Workstation depuis un certain temps, principalement sous Windows XP, Windows Vista et maintenant les systèmes natifs Windows Seven pour exécuter différentes versions de Windows, ainsi que Ubuntu.

Oui, un environnement virtualisé est plus lent qu'un système natif et peut aller de 5 à 100%.

Le problème principal n’est pas tant la charge du processeur que le manque de mémoire physique.

Supposons que votre Windows Seven 64 Ultimate fonctionne sur un système de 4 Gb qui, lorsqu'il est inactif, nécessite près de 1,5 Gb et utilise environ 10% du processeur. Le lancement de la couche supplémentaire de VMware vous coûtera environ 300 Ko et les charges de processeur augmenteront jusqu’à ~ 20%. Ensuite, le lancement d'un système virtuel dans VMware demandera au minimum la quantité de mémoire que vous avez définie pour cette machine virtuelle, qui est au minimum de 1 Go pour tout système correct. Ensuite, vous verrez la charge du processeur ~ 60% si la machine virtuelle est Ubuntu et ~ 80% pour tout type de système d'exploitation Windows récent.

Vous allez maintenant démarrer différentes applications sur cette machine virtuelle.

Si la quantité de mémoire que vous avez définie pour cette machine virtuelle n'est pas suffisante, le système virtualisé commencera à permuter, puis à ralentir considérablement ses performances et sa réactivité.

Si la somme de la quantité de mémoire que vous avez définie pour cette machine virtuelle et de la quantité de mémoire nécessaire pour votre système natif est supérieure à la quantité de mémoire de votre système natif, c'est que votre système natif va échanger, puis ralentir à la fois le système natif et virtualisé.

Donc, cela dépend d’abord de l’équilibre de la mémoire nécessaire pour les machines natives et virtualisées.

Maintenant, c'est presque la même chose avec la charge du processeur. Si une application virtualisée nécessite une charge de processeur importante, et qu'une application native nécessite également une charge de processeur importante, votre système natif devra gérer la priorité et équilibrer la charge du processeur entre ses différentes applications, le système virtualisé n'étant qu'une application. Ce phénomène est un problème classique de charge du processeur que vous pouvez résoudre avec les priorités des applications.

Donc, mon premier conseil si vous devez utiliser la virtualisation est de mettre beaucoup de mémoire dans votre machine, quel que soit le système d'exploitation utilisé en mode natif ou dans une machine virtuelle.

Juste mes 2 cents.

Meilleures salutations.

D'après mon expérience, les machines virtuelles sont toujours beaucoup plus lentes que les machines physiques OUT OF THE BOX.

Vous ne le remarquerez que lorsque vous exécuterez des applications qui frappent le disque et qui sollicitent beaucoup le processeur. J'ai exploité de nombreuses bases de données et serveurs Web sur des machines virtuelles et en tant qu'utilisateur final et compte-rendu des autres utilisateurs finaux (accès à l'application à partir d'un navigateur Web distant, par exemple), l'utilisation de machines virtuelles présente un retard considérable.

Bien sûr, une machine virtuelle correctement configurée peut atteindre 80% (je ne connais pas le nombre réel) ou quelle que soit la vitesse de la machine physique, mais vous finissez par devoir vraiment analyser en profondeur ce que fait l'application et comment la machine virtuelle travaux. Je suppose donc que votre temps de configuration des ordinateurs virtuels en achetant et hébergeant un nouveau serveur est une question de coût.

Pour moi, les machines virtuelles NE SONT PAS UNE PERFORMANCE, mais bien une gestion plus facile et, bien entendu, l'hébergement de plusieurs VM.