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

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.

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

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.

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.

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.

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.