Alors vraiment, quel est le surcoût de la virtualisation et quand dois-je m'inquiéter?

16

Je cherche de bonnes règles de base pour comprendre quand NE PAS virtualiser une machine.

Par exemple, je sais qu'un processus entièrement lié au processeur avec une utilisation à près de 100% n'est probablement pas une bonne idée de virtualiser, mais est-il logique d'exécuter quelque chose qui exploite le processeur la plupart du temps une "quantité substantielle" (disons 40 ou 50%)?

Autre exemple: si je virtualise 1000 machines, même si elles ne sont que légèrement ou modérément utilisées, il serait probablement mauvais de tout exécuter sur un hôte avec seulement 4 cœurs.

Quelqu'un peut-il résumer des conseils sur la virtualisation en fonction de la charge de travail de la machine ou du nombre de machines invitées par rapport aux ressources hôtes?

Je virtualise généralement sur des hôtes Windows en utilisant VirtualBox ou VMWare, mais je suppose que c'est une question assez générique.

kvista
la source
1
même avec certaines tâches liées au processeur, il y a un point à la virtualisation - permettre aux utilisateurs de soumettre des travaux aux clusters en tant qu'images VM leur permet un contrôle beaucoup plus important sur l'environnement dans lequel les travaux s'exécutent qu'il ne serait possible avec un simple programmateur de lots par exemple.
Flexo
Mais à un moment donné, la planification de «l'exécution de VM» semble être une surcharge inutile quand il est déjà assez difficile de planifier des threads au sein d'une seule VM, ai-je raison?
kvista

Réponses:

13

Sous-système de disque. Il s'agit généralement de la ressource la moins partageable. La mémoire, bien sûr, mais celle-là est apparente.

Les limitations du sous-système de disque fonctionnent dans les deux sens. Si un système utilise beaucoup d'E / S disque, d'autres invités ralentissent. Si cet invité est en production, il a probablement besoin d'une réponse rapide aux requêtes Web. Cela peut être très frustrant et aussi une grande raison de ne pas louer de matériel virtuel. Vous pouvez minimiser ce problème en utilisant des disques dédiés.

L'utilisation de seulement 512 Mo de mémoire dans les invités place tout le cache disque sur l'hôte. Et ce n'est pas réparti également entre les invités.

Ne vous inquiétez pas du processeur IO. De cette façon, la virtualisation est très efficace, souvent liée à plusieurs processus exécutés sur le même système. Je vois rarement des systèmes multi-xeon fonctionnant à 100% sur CPU.

modifier: fautes de frappe

Antti Rytsölä
la source
3
les exigences élevées d'E / S disque seraient la raison n ° 1 de ne pas virtualiser - c'est la ressource la plus durement touchée par les pénalités de virtualisation, voir codinghorror.com/blog/2006/10/…
Jeff Atwood
Merci - les deux commentaires sont utiles. Vous vous demandez simplement si quelqu'un sait pourquoi une utilisation élevée du disque est problématique pour la virtualisation? Pourquoi les ingénieurs de virtualisation ignoreraient-ils ce problème relativement basique? Ou est-elle simplement plus complexe que la virtualisation CPU?
kvista
Remarque - @Jeff, je lis votre article de blog de 2006 et je suppose que cela expliquera pourquoi mieux (c.-à-d. Réservation de fuseau), mais ma question aux concepteurs / implémenteurs de virtualisation reste la même - est-ce juste fondamentalement problématique pour la virtualisation dans un moyen de virtualisation CPU n'est pas?
kvista
3
Il n'y a que tant de recherches qu'un disque dur peut faire. Pour un disque dur de 5 ms, cela correspond à 200 recherches par seconde. Et, d'une manière générale, lorsqu'un système d'exploitation copie des fichiers ou analyse des répertoires, il utilise toujours 100% du disque io. Pendant ce temps, toutes les petites requêtes du disque sont retardées, et il y en a beaucoup. Les tampons du système de fichiers sont également gaspillés à cause de la copie. On pourrait dire que notre concept de fonctionnement du système d'exploitation repose sur un disque dur inactif.
Antti Rytsölä
1
Merci. Je suppose qu'il serait intéressant de voir si les SSD changent du tout cette équation. Mais maintenant, nous allons trop loin dans le mode discussion. Je comprends - merci à tous.
kvista
15

Des choses que je ne mettrais jamais dans une VM:

  • Tout ce qui utilise du matériel spécifique qui ne peut pas être virtualisé: généralement des graphiques, pas mal de modules de sécurité matérielle, tout ce qui a des pilotes personnalisés (pilotes de réseau spéciaux, par exemple).

  • Systèmes avec des problèmes de licence. Certains frais logiciels par processeur physique ou cœur, peu importe le peu que vous avez alloué à la machine virtuelle. Vous seriez frappé lors d'un audit si vous aviez un logiciel sous licence pour un seul cœur s'exécutant dans une machine virtuelle sur un serveur 32 cœurs.

Choses que je découragerais de mettre dans une VM:

  • Logiciel qui s'efforce déjà d'utiliser toutes les ressources du matériel de base. Les machines fonctionnant dans le cadre d'un effort de "big data" comme hadoop sont généralement conçues pour fonctionner sur du métal nu.

  • Tout ce qui va être finement réglé pour utiliser les ressources. Lorsque vous commencez vraiment à régler une base de données, les machines virtuelles en lice pour les ressources vont vraiment jeter une clé dans le travail.

  • Tout ce qui a déjà un gros goulot d'étranglement. Il ne joue déjà pas bien avec lui-même, il ne jouera probablement pas bien avec les autres.

Il y a des choses qui sont assez géniales pour installer des VM:

  • Tout ce qui passe beaucoup de temps inactif. Les hôtes utilitaires comme la messagerie et le DNS ont du mal à générer suffisamment de charge sur du matériel moderne pour garantir des serveurs dédiés.

  • Applications qui n'évoluent pas bien (ou facilement) par elles-mêmes. Le code hérité tombe assez souvent dans cette catégorie. Si l'application ne se développe pas pour occuper le serveur, utilisez beaucoup de petits serveurs virtuels.

  • Projets / applications qui commencent petit mais grandissent. Il est beaucoup plus facile d'ajouter des ressources à une machine virtuelle (ainsi que de passer à du matériel plus récent et plus gros) plutôt que de commencer sur du métal nu.

De plus, je ne sais pas si vous exagérez sur le fait de mettre un grand nombre de machines virtuelles sur un seul hôte, mais si vous essayez un grand rapport VM: HW, vous voudrez peut-être envisager ESX, Xen, KVM à la place. Vous vous en sortirez beaucoup mieux que d'utiliser VMware ou virtualbox sous Windows.

Cakemox
la source
1
+1 commentaires organisés très utiles - merci!
kvista
Un autre commentaire - même si j'utilise ESX, etc. Je suppose qu'à un moment donné, il est inutile de placer des machines X sur un hôte Y core. Quelles sont les bonnes règles de base? Je suppose que les livres blancs sur la virtualisation doivent quelque part résoudre ce problème, mais malheureusement je ne suis pas en mesure de le trouver facilement.
kvista
1
Pour VMware, vous pouvez commencer ici: vmware.com/technology/whyvmware/calculator
Cakemox
Pour référence: par le lien VMWare ci-dessus, vous pouvez configurer jusqu'à 30 VM par CPU. La valeur par défaut est 6 VM par CPU.
Alex Yursha
4

Les performances de virtualisation présentent deux points.

  • goulot d'étranglement partagé
  • émulation

Sur les goulots d'étranglement partagés, qui d'autre est sur le même fer? Si vous êtes colocalisé dans un environnement virtualisé, vous êtes très tributaire du fait que l'hébergeur est honnête avec vous.

Je pense que la principale question à poser pour les performances brutes (en particulier l'interactivité) est de savoir quelles parties du système de virtualisation sont émulées. Cela diffère selon la configuration. Le disque et le réseau sont les candidats typiques. En règle générale, l'émulation double le "coût" de performance d'une action, donc tout temps de latence matérielle doit être compté deux fois et tout nombre de débits doit être divisé par deux.

Bittrance
la source
1
les chiffres que j'ai vus étaient CPU à 96-97%, réseau à 70-90% et disque à 40-70% (de métal nu)
Jeff Atwood
1
Le commentaire +1 de la règle d'or est utile.
kvista
2

En fin de compte, aucune charge hautes performances ne doit être virtualisée. Les révisions des performances de la virtualisation ne sont pas triviales. Voir les résultats de mes tests ici:

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

OTOH, si vous cherchez à consolider un certain nombre de machines qui sont pour la plupart inactives en permanence, la virtualisation est la voie à suivre.

Gordan
la source
1

Bonne réponse de l'anttiR.

En outre, les systèmes à temps critique. Je viens de comprendre que la pourriture Hyper-V dime (vm qui prend lentement du retard, tous les systèmes d'exploitation modernes dans vm le font, sont souvent resynchronisés) ne joue pas très bien avec certaines applications critiques que je développe. De plus, je vais utiliser "beaucoup" de processeurs là-bas, et je prévois d'obtenir une machine à 12 cœurs juste pour cette application en production.

TomTom
la source
Asterisk est l'une de ces applications. Vous obtenez des choses très géniales qui se produisent lors des conférences téléphoniques lorsqu'elles sont visualisées.
Ryaner
J'ai le problème avec la stabilité de l'horloge pour les enregistrements de données;) Dieu merci, j'obtiens un horodatage fiable du flux de données, mais il est difficile de savoir s'il y a des problèmes de réseau lorsque l'horloge système n'est pas stable.
TomTom