La planification des gangs utilisée par VMware est-elle un sérieux inconvénient?

Je lisais quelques articles technet ainsi que celui-ci concernant les différences entre la façon dont VMware et Hyper v font la planification du CPU.

Je me demandais si je pouvais obtenir des informations objectives à ce sujet. Il semblerait que la planification des gangs utilisée par VMware soit un énorme inconvénient, mais je ne veux pas simplement boire le coolaid. Cela affecte-t-il sérieusement les performances ou les dernières itérations des hyper-visières de VMware résolvent-elles cela?

Edit: Quand je dis désavantage, je veux dire par rapport à la "planification de processeur libre" d'Hyper V ou de la manière dont KVM le fait. Le matériel que je lisais ne disait pas qu'il y avait des problèmes avec "l'ordonnancement du processeur gratuit" qui sont évités avec l'ordonnancement des gangs.

Comme chanter Bloody Mary dans un miroir de salle de bain sombre, voyons si nous pouvons faire apparaître Jake Oshins ...

La planification des gangs est également appelée co-programmation. Je pense que VMware préfère le terme co-planification à la planification de gangs.

Dans les versions ESX antérieures à la version 3.x, VMware utilisait une co-planification "stricte", qui présentait les inconvénients de la synchronisation. Dans ESX 3.x et versions ultérieures, VMware est passé à une co-planification "détendue".

La co-planification détendue a remplacé la co-planification stricte dans ESX 3.x et a été affinée dans les versions ultérieures pour obtenir une meilleure utilisation du processeur et prendre en charge de larges machines virtuelles multiprocesseurs. La co-programmation détendue a quelques propriétés distinctives par rapport à l'algorithme strict de co-programmation. Le plus important de tous, alors que dans l'algorithme strict de co-ordonnancement, l'existence d'un vCPU en retard entraîne l'arrêt complet de la machine virtuelle. Dans l'algorithme de co-ordonnancement détendu, un vCPU leader décide s'il doit co-arrêter lui-même en fonction de l'inclinaison par rapport au vCPU frère le plus lent. Si l'inclinaison est supérieure à un seuil, le vCPU principal s'arrête lui-même. Notez qu'un vCPU en retard est celui qui fait beaucoup moins de progrès que le vCPU frère le plus rapide, tandis qu'un vCPU leader est celui qui fait beaucoup plus de progrès que le vCPU frère le plus lent. En suivant le vCPU frère le plus lent, il est désormais possible pour chaque vCPU de prendre sa propre décision de co-programmation indépendamment. Comme co-stop, la décision de co-start est également prise individuellement. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles à un co-démarrage et peuvent être planifiés en fonction de la disponibilité du pCPU. Cela résout le problème de fragmentation du processeur dans l'algorithme de co-planification strict en n'exigeant pas un groupe de vCPU à planifier ensemble. Dans l'exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut avancer, même s'il n'y a qu'un seul pCPU inactif disponible. Cela améliore considérablement l'utilisation du processeur. En suivant le vCPU frère le plus lent, il est désormais possible pour chaque vCPU de prendre sa propre décision de co-programmation indépendamment. Comme co-stop, la décision de co-start est également prise individuellement. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles à un co-démarrage et peuvent être planifiés en fonction de la disponibilité du pCPU. Cela résout le problème de fragmentation du processeur dans l'algorithme de co-planification strict en n'exigeant pas un groupe de vCPU à planifier ensemble. Dans l'exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut avancer, même s'il n'y a qu'un seul pCPU inactif disponible. Cela améliore considérablement l'utilisation du processeur. En suivant le vCPU frère le plus lent, il est désormais possible pour chaque vCPU de prendre sa propre décision de co-programmation indépendamment. Comme co-stop, la décision de co-start est également prise individuellement. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles à un co-démarrage et peuvent être planifiés en fonction de la disponibilité du pCPU. Cela résout le problème de fragmentation du processeur dans l'algorithme de co-planification strict en n'exigeant pas un groupe de vCPU à planifier ensemble. Dans l'exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut avancer, même s'il n'y a qu'un seul pCPU inactif disponible. Cela améliore considérablement l'utilisation du processeur. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles à un co-démarrage et peuvent être planifiés en fonction de la disponibilité du pCPU. Cela résout le problème de fragmentation du processeur dans l'algorithme de co-planification strict en n'exigeant pas un groupe de vCPU à planifier ensemble. Dans l'exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut avancer, même s'il n'y a qu'un seul pCPU inactif disponible. Cela améliore considérablement l'utilisation du processeur. Une fois que le vCPU frère le plus lent commence à progresser, les vCPU co-arrêtés sont éligibles à un co-démarrage et peuvent être planifiés en fonction de la disponibilité du pCPU. Cela résout le problème de fragmentation du processeur dans l'algorithme de co-planification strict en n'exigeant pas un groupe de vCPU à planifier ensemble. Dans l'exemple précédent de la machine virtuelle à 4 vCPU, la machine virtuelle peut avancer, même s'il n'y a qu'un seul pCPU inactif disponible. Cela améliore considérablement l'utilisation du processeur. la machine virtuelle peut progresser, même s'il n'y a qu'un seul processeur inactif disponible. Cela améliore considérablement l'utilisation du processeur. la machine virtuelle peut progresser, même s'il n'y a qu'un seul processeur inactif disponible. Cela améliore considérablement l'utilisation du processeur.

L'extrait ci-dessus provient de la propre documentation de VMware .

VMware n'utilise donc plus de planification de gang stricte. Je traiterais la documentation directement du fournisseur comme faisant plus autorité.

La seule chose qui vous donnera des chiffres durs est une référence, et cela dépendra entièrement des types de code que les CPU exécutent. Mais je peux vous dire que si VMware était si désavantagé, il n'aurait pas encore la part du lion du marché de la virtualisation.

D'accord, Ryan, tu as fait ma journée. Je ne lis pas ce forum autant qu'avant, mais il m'est arrivé de m'enregistrer.

Red888, vous devez savoir à l'avance que je suis un architecte logiciel qui travaille sur Hyper-V chez Microsoft. Je suppose que la plupart des gens qui lisent ceci sont parfaitement capables de cliquer sur mon lien de nom en dessous de cela et de découvrir cela, ou même de me googler, mais pour cette réponse, il est utile d'être entièrement certain que les personnes qui lisent ceci n'ont aucun doute sur mon point de vue.

En général, la planification des gangs est utile si l'hyperviseur n'a aucun moyen d'influencer le comportement du système d'exploitation exécuté au sein de la machine virtuelle. C'est, bien sûr, pourquoi VMware a commencé de cette façon. Ils ne possèdent aucun système d'exploitation et leur objectif était donc de faire bien fonctionner les systèmes d'exploitation existants. Si j'étais eux, c'est là que j'aurais commencé.

La planification des gangs, et VMware dirait probablement que j'ai raison à ce sujet, laisse beaucoup de limitations sur la façon dont vous pouvez utiliser les processeurs physiques au sein de la machine. L'hyperviseur ne trouve souvent pas la bonne ressource adaptée pour le moment. Ils ont donc modifié leur algorithme au fil des ans, à la recherche de méthodes de planification plus efficaces.

Microsoft (et probablement plusieurs autres sociétés) a commencé avec une vision différente. Nous possédons Windows. Nous ferons en sorte que Windows se comporte bien lorsqu'il est virtualisé. Et donc la programmation des gangs ne sera pas nécessaire. Nous ne prendrons même pas la peine de créer un planificateur de gangs.

Il est intéressant de noter que chez Microsoft, nous nous soucions plus du bon fonctionnement de Windows par rapport aux autres systèmes d'exploitation que de l'hyper-V qui a l'air mieux que VMware, ou KVM, ou Xen, ou Oracle, ou Unisys, etc. Nous avons donc publié les interfaces que Windows utilise pour coopérer avec un hyperviseur. Voici un lien si vous êtes curieux, bien que je ne le recommande pas comme lecture au coucher:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Ainsi, tout fournisseur d'hyperviseur peut exposer les éléments qui déclencheront un comportement coopératif de Windows. Plusieurs l'ont fait. Honnêtement, je ne sais pas si VMware a, ou fait, ou exposera cela. Il faudrait leur demander, ou quelqu'un qui leur prête beaucoup d'attention. Et s'ils le font, je serais très surpris s'ils n'avaient pas modifié leur agenda pour se détendre encore plus. Cette dernière déclaration, bien sûr, n'est que pure spéculation.

Donc, ma réponse est que je doute que vous devriez prendre une décision d'achat en 2014 en fonction du fonctionnement du planificateur d'hyperviseur. Je soupçonne qu'ils sont tous assez bons maintenant. Il y a quelques années, cela n'était peut-être pas vrai.

Vous devriez essayer vos charges de travail sur les différents systèmes et voir comment ils fonctionnent. Je parie que vos performances ultimes se résument à savoir si votre stockage et votre réseau répondent à vos besoins.