Co-Scheduling
Le « co-scheduling » , de manière générale, permet d’exécuter un ensemble
de threads ou processus d’un même groupe en parallèle sur plusieurs CPU afin
d’avoir de meilleures performances.
Dans le cas de VMware, le but est de faire fonctionner plusieurs vCPU d’une VM en même temps.
Dans le cas de VMware, le but est de faire fonctionner plusieurs vCPU d’une VM en même temps.
Hyperthreading
Pour assurer de meilleures performances, l’ordonnanceur
va distribuer les vCPU d’une VM sur différents pCPU, surtout avec de l’hyperthreading.
Cependant il y a une contrainte, à chaque instant un
seul thread peut s’exécuter sur un cœur. Si on positionne les 2 vCPU d’une VM
sur les 2 threads d’un même cœur, alors à chaque cycle de temps CPU, un seul
vCPU pourra s’exécuter. Si cette VM a une forte activité CPU, elle ne profitera
pas de ses 2 vCPU puis qu’elle s’exécute sur un seul cœur. L’ordonnanceur va
donc rediriger chaque vCPU sur des cœurs différents.
Seconde contrainte: un OS traditionnel exige que ses processeurs travaillent de
manière synchrone. L’ensemble de ses
processeurs doivent répondre dans un délai spécifique, sinon l’OS risque de
crasher (kernel panic ou Blue Screen).
Pour répondre à cette problématique, VMware a d’abord mis au
point le « Strict Co-Scheduling » avec ESX 2.0. Puis il y eu un
changement majeur avec le « Relaxed Co-Scheduling » apparu dans la
version ESX 3.0. Depuis le « Relaxed Co-Scheduler » est amélioré à
chaque nouvelle version majeure :
De base, l’ordonnanceur essaie de schéduler tous les vCPU
d’une VM en même temps. S’il n’y a pas assez de cœurs physiques disponibles, l’implémentation
du co-scheduling permet à un ESXi quelques flexibilités : il schédule
uniquement les vCPU qui doivent exécuter des instructions tout en maintenant
l’illusion que les vCPU d’une VM sont synchrones.
Pour cela, l’ESXi maintient
un « skew » (retard) par vCPU. Ce skew augmente lorsque le vCPU ne travaille pas
tandis que les autres vCPU de la VM travaillent. Lorsque le skew atteint un
certain seuil, le comportement change en fonction du mécanisme utilisé : Strict co-scheduling ou Relaxed Co-Scheduling
Strict co-scheduling
De manière simple, le skew est cumulatif pour chaque vCPU. Un vCPU, qui n’est pas exécuté alors qu’il a des tâches à faire, cumule du skew. Si ce skew dépasse une certaine limite, on déschedule la VM entièrement (on dit qu’elle est Co-stoppée).
Dans le calcul du skew, on ne prend pas en compte le temps qu’un vCPU passe en
IDLE. Par exemple, si une VM avec 4 vCPU exécute une application mono-thread,
elle n’a besoin que d’un seul pCPU et ne sera jamais co-stoppée. La métrique Co-Stop indique donc le pourcentage de temps que
la VM est Co-Stoppée et attend d’avoir autant de pCPU libres que de vCPU.
La VM sera ensuite "co-startée" uniquement lorsqu'il y aura assez de pCPU disponibles pour exécuter tous les vCPU simultanément. La VM repassera alors en mode READY et pourra ainsi être schédulée (Dispatch).
La VM sera ensuite "co-startée" uniquement lorsqu'il y aura assez de pCPU disponibles pour exécuter tous les vCPU simultanément. La VM repassera alors en mode READY et pourra ainsi être schédulée (Dispatch).
Ce type de co-scheduling introduit de la fragmentation CPU. Par exemple, si vous avez une VM avec 4 vCPU, et que seulement 3 pCPU sont libres, celle-ci va commencer à exécuter ses différents threads puis va rapidement être co-stoppée et ne pourra plus s’exécuter tant qu’un 4e pCPU ne sera pas disponible.
Relaxed Co-Scheduling
Avec la nouvelle version « Relaxed Co-Scheduling »,
lorsque le skew dépasse la limite, seuls les vCPUs de la VM qui sont trop en
avances, sont placés en mode COSTOP. La VM n’est donc pas entièrement figée et
continue de travailler.
On traque toujours le vCPU le plus en retard grâce au
« Skew ». Si le skew dépasse une limite, le vCPU qui est en avance,
passe de lui-même en mode COSTOP pour attendre les autres. Une fois que le vCPU
le plus lent a rattrapé son retard, les autres vCPU peuvent d’eux même se « co-starter ». Ils repassent donc dans le mode READY et peuvent être exécutés si un pCPU est disponible.
Par exemple, une VM avec 8 vCPU peut avancer dans ses tâches
même s’il n’y a que 4 pCPU de disponibles. Cela améliore donc grandement le
taux d’utilisation des pCPU. Par contre, si 8 pCPU sont disponibles, alors
l’ESXi va faire en sorte d’exécuter les 8 vCPUs en même temps.
Depuis vSphere 5.X, de nombreuses améliorations ont été
apportées afin de supporter jusqu’à 64 vCPUs par VM en version 5.5 et 128 vCPUs
par VM en version 6.0.
Nous venons donc répondre à la question initiale qui a lancé ce topic :)
Dans une prochaine partie, nous pousserons le sujet un peu plus loin et nous aborderons le Load Balacing, NUMA et vNUMA.
0 commentaires :
Enregistrer un commentaire