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, je suis intéressé à savoir si la machine virtuelle exécutant Ubuntu Enterprise Cloud sera plus lente que la même machine physique sans virtualisation. Combien (1%, 5%, 10%)?
Quelqu'un a-t-il mesuré la différence de performances du serveur Web ou du serveur DB (virtuel VS physique)?
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. En plus de cela, une seule machine virtuelle a permis d'utiliser toutes les ressources disponibles.
L'expérience typique d'une charge de travail de serveur à usage général sur un hyperviseur bare metal\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 l'ensemble IO charge. Cela est à peu près cohérent dans mon expérience pour les systèmes d'exploitation 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 du matériel qui prend 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 supplémentaire de 1%. 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 que être sensiblement 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 dépasser les serveurs nus\discrets. Voici un exemple de discussion sur la façon dont une implémentation en cluster VMware peut être plus rapide\meilleure\moins chère qu'un Oracle RAC sans système d'exploitation. Les techniques de gestion de la mémoire de VMware (en particulier le partage de pages transparent) peuvent éliminer la surcharge de mémoire presque entièrement si vous avez suffisamment de machines virtuelles suffisamment similaires. L'important dans tous ces cas est que les avantages de performance\efficacité 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) être toujours plus lent que le métal nu dans une certaine mesure.
Bien que tout cela soit utile, les vrais problèmes en termes de virtualisation de serveur ont tendance à être centrés sur la gestion, les techniques de haute disponibilité et l'évolutivité. Une marge de performances de 2 à 5% n'est pas aussi importante que de pouvoir évoluer efficacement jusqu'à 20, 40 ou le nombre de machines virtuelles dont vous avez besoin sur chaque hôte. Vous pouvez gérer les performances atteintes en sélectionnant un processeur légèrement plus rapide comme référence, 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 l'environnement est difficile à gérer ou peu fiable alors sa valeur d'un point de vue de virtualisation de serveur.
La "performance" a de nombreux aspects. Le n00bs mesure le temps de démarrage d'un système d'exploitation et dit par exemple Windows 2012 est tellement génial car il démarre en 12 secondes sur du vrai HD, peut-être 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 le système d'exploitation démarre une fois par mois, l'optimisation n'a donc pas beaucoup de sens.
Parce que c'est mon travail quotidien, je pourrais souligner les 4 parties suivantes qui composent la "performance"
charge CP
Cela devrait être comparable, ce qui signifie qu'une tâche prenant 1000 ms sur du métal nu s'exécutera 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 (certains détails plus tard). Google le MSDN pour processtime et queryperformancecounter et vous pouvez faire une chose qui peut montrer combien le VM mange votre temps CPU.performances SQL
Les performances SQL reposent fortement sur IO vers le magasin de données où les données SQL sont stockées. J'ai vu une différence de 300% entre l'ISCSI de 1ère génération que vous pouvez trouver sur le NAS de Buffalo, puis l'ISCSI avec DCE et un véritable environnement FC old school, à tous les niveaux. Le FC gagne toujours de nos jours, car la latence FC est la plus faible archivable qui mène à une "copie" du protocole FC pour les améliorations du centre de données TCP/IP. Ici, les IOps et la latence sont vitaux, mais aussi IO la bande passante du processus serveur vers le média - dépend si l'application a tendance à No-SQL ou à Datawarehousing ou est au milieu de cela comme ERP systèmes ... Sage KHK pour les petites entreprises, SAP pour les grandes. Les deux ont une vision du PDG sur les statistiques financières des entreprises et lorsque le PDG appuie sur le bouton, il accorde effectivement des vacances pendant quelques jours lorsque le sous-système IO de la base de données présente des faiblesses.Accès au système de fichiers
Certaines applications, comme le streaming vidéo, reposent sur une bande passante minimale garantie, d'autres s'appuient sur le débit max IO comme simplement ouvrir de gros fichiers dans un éditeur hexadécimal, charger un projet vidéo dans votre programme de création de films préféré . Pas une situation typique sur un vm .... les IOps peuvent également être importants pour les développeurs. Les développeurs utilisent souvent des VM car les environnements de développement sont très sensibles et donc la tentation de le faire dans un VM est élevée. Compiler un grand projet signifie souvent lire des tonnes de petits fichiers, faire le truc du compilateur et construire un EXE et les composants qui l'accompagnent.Latence réseau vers le client
Ici, l'utilisabilité des progs WYSIWIG comme Word 2010, Openoffice Writer, LaTEX, GSView et d'autres dépendent fortement de la vitesse - la vitesse à laquelle une action de la souris passe du client au serveur. Surtout dans les applications CAD c'est important .... mais pas non plus un problème de LAN, c'est l'accès à distance sur WAN où c'est important.
Mais - et je parle du point de vue d'années de consultation - il y a des utilisateurs qui ont le mot de passe administrateur (et ils sont souvent des employés d'une GRANDE entreprise avec un GRAND budget et un GRAND portefeuille) se plaignant ceci et cela, mais cela doit être clarifié quel composant de performance est important pour eux et lequel est important du point de vue de l'application qu'ils utilisent.
Ce n'est probablement pas un bloc-notes, mais une application très sophistiquée pour l'ingénierie de ceci et cela, qui était également très coûteux et devrait être déplacé sur VMware, HyperV ou Xenapp et il ne fonctionne pas comme prévu.
Mais ils n'ont pas à l'esprit qu'il pourrait fonctionner sur des Xeons à 1,5 GHz sur des lames non conçues pour des performances CPU pures, ils sont construits pour une moyenne, disons "optimisés pour $ par cycle CPU" ou "cycles CPU par Watt" .
Et lorsque nous parlons de compromis et d'économisations - cela conduit principalement à des engagements excessifs. Les engagements excessifs entraînent un manque de ressources où le processeur peut être géré assez bien, mais le manque de mémoire conduit à la pagination, le manque de IO dans les routeurs principaux entraîne une augmentation des temps de réponse sur tout, et une surcharge transactionnelle sur tout type de le stockage peut empêcher chaque application utile de répondre trop rapidement. Ici, la surveillance est requise, mais de nombreux éditeurs de logiciels ne sont pas en mesure de fournir de telles informations .... en revanche, un hôte disposant de ressources de 3 serveurs physiques peut très probablement gérer 8 machines virtuelles de même configuration que les physiques ...
Les compromis du CPU sur les systèmes inactifs conduisent souvent à des systèmes 50% plus lents que les systèmes physiques, d'autre part, personne n'est en mesure d'installer le système d'exploitation "réel" et l'application "réel" que les informaticiens du client veulent déplacer dans le VM boîte. Et il faut des jours (peut-être des semaines mais certainement 42 réunions) pour montrer clairement que la technologie VM peut offrir de la flexibilité en échangeant une vitesse CPU pure. Ceci est simplement intégré dans les CPU de ces systèmes de lame hébergeant de nos jours des environnements VM plus grands. De plus, la mémoire ne sera pas comparable, certains compromis s'appliquent également. Le DDR3 1600 CL10 aura une bande passante mémoire plus élevée que le 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 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 datacenter peut être partout s'il présente moins de 150 ms de latence entre l'utilisateur final et le datacenter.
Et le point de vue des utilisateurs à domicile ....
Enfin, certaines personnes veulent jeter Win7 ou XP et l'échanger contre un Linux, puis la question du jeu se pose car en fait, seuls quelques jeux sont disponibles pour Linux et Windows. Le jeu repose fortement sur 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 un VM peut s'exécuter sur la carte graphique hôte en plein écran. Les jeux sont pour la plupart des applications 32 bits, donc ils ne consommeront pas plus de 3 Go et surtout pas plus de 3 processeurs (vu sur Crysis). Les nouveaux joueurs VM et WS peuvent gérer les versions DirectX supérieures et probablement OpenGL aussi ... J'ai joué UT et UT2004 sur VMware 6.5, l'hôte avait un mobile ATI Radeon 2600 et un T5440 CPU. 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égligeable (1% à 5%).
Je voudrais 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 lan spécifique), les machines virtuelles sur le même serveur peuvent communiquer entre elles à des vitesses supérieures à celles de plusieurs serveurs phyiscaux avec un équipement réseau moyen.
J'ai fait des comparaisons de tests du même logiciel exécutant le même test (application Web basée sur .NET avec des volumes élevés de trafic Web et un accès considérable à SQL Server). Voici ce que j'ai vu:
- La machine physique est meilleure pour instancier des classes (ce qui se traduit par l'allocation de mémoire au niveau du système) - cela a du sens pour moi car les machines physiques le font via le matériel de gestion de la mémoire et les machines virtuelles le font via le 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 équivalents - c'est probablement la façon dont la plupart des repères sont construits qui montrent que les deux "sont les mêmes"
- Lorsque vous accédez à un contrôleur réseau, le physique bat le VM un peu - encore une fois, le physique n'a pas grand-chose entre le processus .NET et le matériel. VM ajoute ajoute d'autres "trucs" que chaque transaction doit parcourir.
- Vraiment, la même chose s'appliquait à l'accès au disque (SQL Server était sur une autre machine) - la différence est très petite, mais quand vous les additionnez toutes, c'est perceptible. Cela peut être dû à un accès au réseau plus lent ou à un accès au disque plus lent.
Je peux facilement voir comment quelqu'un pourrait créer des repères qui prouvent qu'ils sont différents de 1% ou identiques ou que les machines virtuelles sont plus rapides. N'incluez rien dans lequel votre processus tire parti des avantages du support matériel local lorsque le VM doit le simuler dans le logiciel.
Vous essayez de comparer un système d'exploitation, un logiciel et des données installés sur un certain matériel physique à ce même système d'exploitation, logiciel et données installés par lui-même à l'intérieur d'un hyperviseur sur le même matériel d'origine. Cette comparaison n'est tout simplement pas valide, car presque personne ne le fait (au moins au début). Bien sûr, cela serait probablement plus lent. Heureusement, il manque complètement le point le plus courant de la raison pour laquelle vous virtualisez les serveurs.
Un meilleur exemple ici 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 maintenant et qui entrent dans leur cycle de rafraîchissement. Ces serveurs fonctionnent déjà bien sur du matériel plus ancien, et donc grâce à la loi de Moore, tout ce que vous obtiendrez sera beaucoup trop spécifié.
Donc que fais-tu? C'est simple. Plutôt que d'acheter deux nouveaux serveurs, vous n'en achetez qu'un, puis migrez vos deux anciens serveurs vers le même nouvel appareil physique. Lors de la préparation de l'achat de votre nouveau serveur, vous prévoyez de disposer d'une capacité suffisante pour gérer non seulement la charge des deux serveurs plus anciens, mais également toute charge de l'hyperviseur (et peut-être un peu plus, de sorte que vous puissiez toujours obtenir une amélioration des performances et peut permettre la croissance).
En résumé: les machines virtuelles offrent des performances "assez bonnes" pour la plupart des situations et vous aident à mieux utiliser vos serveurs pour éviter une puissance de calcul "gaspillée".
Maintenant, étendons cela un peu plus. Comme ce sont de vieux serveurs, vous envisagiez peut-être quelques serveurs de boîtes à pizza simples de 1 500 $ pour les remplacer. Il y a de fortes chances que même une de ces boîtes à pizza puisse encore facilement gérer la charge des deux anciennes machines hypothétiques ... mais disons que vous décidez de dépenser 7500 $ ou plus pour du vrai matériel à la place. Vous disposez maintenant d'un appareil qui peut facilement gérer jusqu'à une douzaine de vos serveurs existants (selon la façon dont vous gérez le stockage et la mise en réseau), avec un coût initial de seulement 5. Vous avez également l'avantage de ne gérer qu'un seul serveur physique, le découplage votre logiciel à partir de votre matériel (c'est-à-dire que l'actualisation du matériel est désormais moins susceptible d'avoir besoin d'une nouvelle licence Windows ou de provoquer des temps d'arrêt), vous économisez une tonne d'énergie et votre hyperviseur peut vous fournir de meilleures informations sur les performances que vous n'en aviez dans le passé . Obtenez-en deux et selon la taille de votre ordinateur, votre centre de données entier ne compte plus que deux machines, ou peut-être souhaitez-vous utiliser le deuxième serveur comme serveur de secours pour raconter une meilleure histoire de haute disponibilité.
Mon point ici est que ce n'est pas seulement une question de performances. Je ne prendrais jamais un serveur de production parfaitement bon et le virtualiserais seul avec du matériel équivalent simplement parce que. Il s'agit davantage d'économies de coûts et d'autres avantages que vous pouvez retirer de la consolidation, comme la haute disponibilité. La réalisation de ces avantages signifie que vous déplacez des serveurs vers un matériel différent, ce qui signifie que vous devez prendre le temps de dimensionner ce matériel de manière appropriée, notamment en tenant compte de la pénalité d'hyperviseur. Oui, vous pourriez avoir besoin d'un peu plus de puissance de calcul au total que si chacune de ces machines était sur leur propre appareil physique (indice: vous avez probablement besoin de beaucoup moins de puissance de calcul totale), mais ça va être un - beaucoup moins cher, plus économe en énergie et plus facile à entretenir pour exécuter un serveur physique que pour en exécuter plusieurs.
Il semble que Microsoft ait effectué des tests de référence à l'aide du serveur BizTalk et de 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
Je viens de passer à un SSD (OCZ Vertex 2) et j'exécute mon XP VM environnement de développement dessus, je suis développeur de logiciels. Une chose que je J'ai remarqué que lorsque je lance un programme (un assez gros pour prendre du temps à charger), un noyau du CPU virtuel se détache. Cela se produit lors du chargement de IE également. Puisque le CPU se détache , Je suppose que le goulot d'étranglement est le CPU et non le SSD. Mais cela semble étrange, j'ai le sentiment que si la même chose était faite sur une machine physique, cela se chargerait plus rapidement et mon sentiment est qu'il y a un supplément de traitement supplémentaire VMWare fait que consomme CPU sur l'accès au disque.
Par exemple, j'utilise Delphi et sur une machine physique avec un disque dur normal, le démarrage à froid peut prendre 20 secondes. Dans le VM fonctionnant avec un SSD, il se charge en 19 secondes à partir d'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 ne l'ai pas fait Vérifiez l'utilisation du processeur sur la machine physique, il est possible que le processeur soit également le goulot d'étranglement.
Mais la sensation du VM est que l'accès au disque taxe la VM.
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 avez besoin qu'il soit rapide, installez-le directement sur le matériel. De l'autre côté, si vous avez besoin de flexibilité, d'évolutivité (et de tous les autres avantages de virtualisation: P) déployez une machine virtuelle. Ce sera plus lent, mais à mon humble avis, dans certains cas, c'est justifié et les performances ne sont pas significativement lentes.