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

L'expérience typique d'une charge de travail d'un serveur à usage général sur une machine nue. \Type 1 L'hyperviseur représente environ 1 à 5 % de la surcharge du processeur et 5 à 10 % de la surcharge de la mémoire, avec une surcharge supplémentaire qui varie en fonction de la charge d'E/S globale. D'après mon expérience, ces chiffres sont assez cohérents pour les systèmes d'exploitation invités modernes fonctionnant sous VMware ESX. \ESXi Microsoft Hyper-V et Xen, lorsque 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 du matériel prenant en charge les extensions de virtualisation matérielle de processeur les plus récentes, je m'attends à ce que tous les hyperviseurs de type 1 se dirigent vers ce chiffre de 1% d'overhead. La maturité de KVM n'est pas tout à fait à la hauteur de Xen (ou VMware) à ce stade, mais je ne vois aucune raison de penser qu'il serait sensiblement pire qu'eux pour l'exemple que vous décrivez.

Pour des cas d'utilisation spécifiques, bien que l'ensemble des \aggregate Les "performances" d'un environnement virtuel peuvent dépasser celles des serveurs discrets. Voici un exemple de discussion sur la façon dont une implémentation VMware Clustered peut être plus rapide. \better\cheaper qu'un Oracle RAC en métal nu. Les techniques de gestion de la mémoire de VMware (en particulier le partage transparent des pages) peuvent éliminer presque entièrement la surcharge de mémoire si vous avez suffisamment de machines virtuelles similaires. Dans tous ces cas, l'important est que les performances soient plus élevées. \efficiency Les avantages que la virtualisation peut offrir ne seront réalisés que si vous consolidez plusieurs VM sur des hôtes, votre exemple (1 VM sur l'hôte) sera toujours plus lent que le métal nu dans une certaine mesure.

Bien que tout cela soit utile, les véritables problèmes en termes de virtualisation de serveurs sont généralement centrés sur la gestion, les techniques de haute disponibilité et l'évolutivité. Une marge de 2 à 5 % sur les performances du processeur n'est pas aussi importante que la possibilité d'évoluer efficacement vers 20, 40 ou tout autre nombre de machines virtuelles dont vous avez besoin sur chaque hôte. Vous pouvez gérer l'impact sur les performances en choisissant un CPU légèrement plus rapide comme base de référence, ou en ajoutant plus de nœuds dans vos clusters, mais si l'hôte ne peut pas faire évoluer le nombre de VM qu'il peut exécuter, ou si l'environnement est difficile à gérer ou peu fiable, alors il ne vaut rien du point de vue de la virtualisation des serveurs.

La "performance" a de nombreux aspects. Les débutants mesurent le temps de démarrage d'un système d'exploitation et disent, par exemple, que Windows 2012 est tellement génial qu'il démarre en 12 secondes sur un vrai disque dur et peut-être en 1 seconde sur un disque dur 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 le système d'exploitation ne démarre qu'une fois par mois et l'optimiser n'a pas beaucoup de sens.

Parce que c'est mon travail quotidien, je peux souligner les 4 parties suivantes qui ont constitué la "performance".

1. Charge du CPU
   Cela devrait être comparable, ce qui signifie qu'une tâche qui prend 1000 ms sur du métal nu sera exécutée en 1000 ms de temps de processus et probablement 1050 ms de temps d'horloge dans un environnement VM inactif sur le même matériel (quelques détails plus tard). Cherchez dans le MSDN les mots processtime et queryperformancecounter et vous pourrez faire un truc qui montre combien la VM consomme de temps CPU.

2. Performances SQL
   Les performances de SQL dépendent fortement des entrées/sorties vers le datastore où sont stockées les données SQL. J'ai constaté une différence de 300 % entre l'ISCSI de première génération, que l'on peut trouver sur les NAS domestiques de Buffalo, puis l'ISCSI avec DCE et un véritable environnement FC de la vieille école, à tous les niveaux. Le FC l'emporte encore aujourd'hui, car la latence du FC est la plus faible possible, ce qui a conduit à une "copie" du protocole FC pour les améliorations du centre de données TCP/IP. Ici, l'IOps et la latence sont vitaux, mais aussi la bande passante IO du processus serveur au média - cela dépend si l'application tend vers le No-SQL ou vers le Datawarehousing ou se trouve au milieu de cela comme les systèmes ERP ... Sage KHK pour les petites entreprises, SAP pour les grandes. Les deux ont une vue du PDG sur les statistiques financières de l'entreprise et lorsque le PDG appuie sur le bouton, il accorde effectivement des vacances pour quelques jours lorsque le sous-système IO de la base de données a des faiblesses.

3. Accès au système de fichiers
   Certaines applications, comme le streaming vidéo, dépendent d'une bande passante minimale garantie, d'autres dépendent d'un débit d'E/S maximal, comme l'ouverture de gros fichiers dans un éditeur hexadécimal, le chargement d'un projet vidéo dans votre logiciel de création de films préféré. Ce n'est pas une situation typique sur un vm.... les IOps peuvent également être importants pour les développeurs. Les développeurs utilisent souvent les VMs car les environnements de développement sont très sensibles et la tentation de le faire dans une VM est grande. Compiler un grand projet signifie souvent lire des tonnes de petits fichiers, faire le travail de compilation et construire un EXE et les composants qui l'accompagnent.

4. Latence du réseau vers le client
   La convivialité des logiciels WYSIWIG tels que Word 2010, Openoffice Writer, LaTEX, GSView et d'autres dépend fortement de la vitesse - la rapidité avec laquelle une action de la souris passe du client au serveur. C'est particulièrement important pour les applications de CAO : .... mais ce n'est pas non plus un problème de réseau local, c'est l'accès à distance sur le réseau étendu qui est important.

Mais - et je parle du point de vue d'années de conseil - certains utilisateurs disposant du mot de passe d'administrateur (et il s'agit souvent d'employés d'une GRANDE entreprise avec un GRAND budget et un GRAND portefeuille) se plaignent de ceci et de cela, mais il faut clarifier quel composant de performance est important pour eux et lequel est important du point de vue de l'application qu'ils utilisent.
Il ne s'agit probablement pas du bloc-notes, mais d'une application très sophistiquée pour l'ingénierie, qui a également coûté très cher et qui devrait être déplacée sur VMware, HyperV ou Xenapp, et qui ne fonctionne pas comme prévu.

Mais ils n'ont pas à l'esprit qu'il pourrait fonctionner avec des Xeons à 1,5 GHz sur des lames qui ne sont pas conçues pour des performances de CPU pures, elles sont construites pour une moyenne, disons "optimisée pour $ par cycle de CPU" ou "cycles de CPU par Watt".

Et lorsque nous parlons de compromis et d'économies, cela conduit le plus souvent à des engagements excessifs. Les surengagements conduisent à un manque de ressources où le CPU peut être géré assez bien, mais le manque de mémoire conduit à la pagination, le manque d'E/S dans les routeurs centraux conduit à des temps de réponse accrus sur tout, et la surcharge transactionnelle sur tout type de stockage peut empêcher toute application utile de répondre trop rapidement. C'est là qu'une surveillance est nécessaire, mais de nombreux fournisseurs de logiciels ne sont pas en mesure de fournir de telles informations. .... D'autre part, un hôte disposant des ressources de 3 serveurs physiques peut très probablement gérer 8 machines virtuelles ayant la même configuration que les serveurs physiques...

Les compromis de CPU sur les systèmes inactifs conduisent souvent à des systèmes fonctionnant 50% plus lentement que les systèmes physiques, d'autre part, personne n'est en mesure d'installer le "monde réel" os et le "monde réel" app que les gars IT du client veulent déplacer dans la boîte VM. Et il faut des jours (peut-être des semaines, mais en tout cas 42 réunions) pour faire comprendre que la technologie VM peut offrir de la flexibilité en échangeant la vitesse pure du CPU. Cela fait partie intégrante des processeurs de ces systèmes lames qui hébergent aujourd'hui des environnements VM plus importants. La mémoire ne sera pas non plus comparable, et certains compromis s'appliquent également. La DDR3 1600 CL10 aura une bande passante mémoire plus élevée que la DDR2 800 ECC LLR - et tout le monde sait que les CPU Intel en profitent d'une manière différente des cpus AMD. Mais ils sont rarement utilisés dans des environnements productifs, plutôt dans des boîtes blanches ou dans des centres de données hébergés dans des pays du tiers monde qui offrent un service de centre de données pour 10% du prix qu'un centre de données dans votre propre pays peut vous facturer. Grâce à Citrx, un centre de données peut être partout s'il y a moins de 150 ms de latence entre l'utilisateur final et le centre de données.

Et la perspective des utilisateurs à domicile....

Enfin, certaines personnes veulent se débarrasser de Win7 ou XP et l'échanger contre un Linux, et la question des jeux se pose alors, car seuls quelques jeux sont disponibles pour Linux et Windows. Les jeux dépendent fortement de l'accélération 3D. VMWare 6.5 Workstation et le lecteur gratuit connecté peuvent gérer DirectX 9, ce qui signifie qu'un Doom3 dans une VM peut fonctionner sur la carte graphique hôte en plein écran. Les jeux sont pour la plupart des applications 32 bits, de sorte qu'ils ne consomment pas plus de 3 Go et surtout pas plus de 3 processeurs (comme dans le cas de Crysis). Les lecteurs VM et WS plus récents peuvent gérer des versions DirectX plus élevées et probablement OpenGL aussi... J'ai joué à UT et UT2004 sur VMware 6.5, l'hôte avait une ATI Radeon 2600 mobile et un CPU T5440. C'était stable à 1280x800 et jouable même sur des jeux en réseau.....

Je tiens à souligner que la virtualisation peut dépasser les performances physiques dans certaines situations. La couche réseau n'étant pas limitée à une vitesse de l'ordre du gigabit (même si l'émulation matérielle est celle d'une carte lan spécifique), les machines virtuelles d'un même serveur peuvent communiquer entre elles à des vitesses supérieures à celles de plusieurs serveurs physiques dotés d'un équipement réseau moyen.

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

J'ai effectué quelques comparaisons du même logiciel exécutant le même test (application web basée sur .NET avec de gros volumes de trafic web et un accès considérable au serveur SQL). Voici ce que j'ai constaté :

• La machine physique est meilleure pour l'instanciation 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 par le biais d'un matériel de gestion de la mémoire et les machines virtuelles le font par le biais de logiciels (avec une assistance matérielle partielle) (sur la machine virtuelle, l'application a passé une quantité significative 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 équivalents - c'est probablement ainsi que sont construits la plupart des points de référence qui montrent que les deux sont "identiques".
• Lorsque vous accédez à un contrôleur réseau, le physique bat un peu la VM - encore une fois, le physique n'a pas grand-chose entre le processus .NET et le matériel. La VM ajoute d'autres "trucs" que chaque transaction doit traverser.
• En fait, la même chose s'est produite pour l'accès au disque (le serveur SQL était sur une autre machine) - la différence est très faible, mais quand on les additionne, elle est perceptible. Cela pourrait être dû à un accès réseau plus lent ou à un accès disque plus lent.

Je peux facilement voir comment quelqu'un pourrait construire des benchmarks prouvant qu'ils sont différents ou identiques à 1% ou que les VM sont plus rapides. N'incluez rien où votre processus profite des avantages du support matériel local alors que la VM doit le simuler en logiciel.