Le processeur

Le processeur 1. Fonctionnement Avant d’expliquer son fonctionnement, définissons les termes qui vont être utilisés : un processeur physique = un socket un processeur logique = un cœ ur x nombre de thread un cœ ur physique = un cœ ur (sans tenir compte des threads) En 2009, le licensing VMware se fait sur le nombre de processeurs physiques (limité à 6 ou 12 cœ urs par processeur selon les éditions (cf. chapitre Architecture de l’infrastructure sous VMware vSphere 4) et non sur le nombre de cœ urs. Le nombre maximum de processeurs logiques par hôte est de 64. a. La gestion du processeur par ESX Cette gestion est structurée de la manière suivante (ici, deux processeurs physiques avec quatre cœ urs chacun) : Les instructions du processeur virtuel (appelé vCPU) des Guest OS sont interceptées par les VMM et transmises au VMkernel. Le VMkernel se charge de répartir dynamiquement à intervalles réguliers la charge de travail des VM sur les différents processeurs (ou cœ urs dans le cas d’un processeur multicœ ur) du serveur. Les instructions des VM sont ainsi migrées d’un processeur (ou un cœ ur) à un autre en fonction de la charge de chaque processeur. Le service console ne tourne que sur le CPU 0 (premier cœ ur du premier processeur physique). Il est possible de dédier une VM à un processeur (appelé Scheduling Affinity). Dans ce cas, la VM ne tournera que sur le processeur défini et ne sera pas migrée sur d’autres cœ urs. Le processeur est le seul composant du serveur qui n’est pas masqué par la couche de virtualisation. Le Guest OS voit donc le type et le modèle du processeur physique du serveur sur lequel il s’exécute. © ENI Editions - All rigths reserved - Guillaume DUBOIS
- 1-
2. Les processeurs au service de la virtualisation a. Le multicœur et la virtualisation Certaines études d’Intel ont montré que l’augmentation de la fréquence apporte un gain de 13 % de performances pour une consommation électrique en hausse de 73 %. En revanche, en ajoutant un cœ ur tout en réduisant leur fréquence de 20 %, les performances sont augmentées de 70 % avec uniquement 2 % de consommation électrique supplémentaire. Si deux autres cœ urs sont ajoutés, la consommation totale est à peine augmentée de 6 % pour une augmentation de 210 % des performances ! Le multicœ ur permet donc de réduire de manière considérable la consommation électrique tout en ayant de très bonnes performances. La virtualisation est l’une des technologies exploitant le mieux les possibilités des multicœ urs car ESX sait gérer un cœ ur comme un processeur physique. Il est donc intéressant d’avoir un grand nombre de cœ urs afin d’atteindre des taux de consolidation importants. Aujourd’hui certains processeurs possèdent six cœ urs mais il est probable que dans quelques années, il y aura plusieurs dizaines voire centaines de cœ urs dans les processeurs afin d’atteindre des taux de consolidation encore plus importants. b. Le SMP et le vCPU SMP (Symmetric MultiProcessing) et vSMP (Virtual SMP)
Il s’agit pour un système d’exploitation d’adresser plusieurs processeurs différents simultanément en parallélisant les tâches d’exécution appelé le multithread. Cela permet d’équilibrer la charge entre les processeurs. En théorie cela peut paraître très intéressant mais en pratique il faut prendre certaines précautions. Un serveur avec plusieurs processeurs physiques peut exploiter le SMP et en tirer des bénéfices si l’application a été développée pour gérer ce parallélisme des tâches d’exécution. Mais en pratique, excepté pour quelques applications de type bases de données (Microsoft SQL, Oracle, IBM DB2) ou des applications métiers ou scientifiques, il existe très peu d’applications en multithread. En effet, il est nécessaire de redévelopper les applications si elles n’ont pas été conçues de base pour du SMP. Dans certains cas, l’utilisation du SMP peut même dégrader les performances car une VM configurée avec 2 vCPU nécessite que les deux processeurs soient disponibles en même temps pour traiter la tâche ce qui en environnement partagé risque de créer des contentions. vSMP est l’exploitation du SMP en environnement virtuel. De manière générale, avant d’utiliser le SMP, il convient de se renseigner auprès des éditeurs de logiciels. vCPU
Le Guest OS travaille avec des processeurs virtuels dit vCPU. Sous vSphere 4, il est possible de configurer une VM avec 1, 2, 4 ou 8 vCPU permettant d’exploiter le SMP. Il faut noter que le Guest OS doit également pouvoir supporter le SMP. Si plusieurs applications tournent sur le même serveur, il est possible de configurer la VM avec plusieurs vCPU, les performances sont ainsi améliorées car les programmes peuvent tourner sur différents processeurs simultanément. En pratique, les pré­requis systèmes (OS, service pack...) peuvent rendre incompatibles les différentes applications, rendant impossible leur cohabitation. De plus, cette configuration augmente le risque de conflits dans la gestion de la mémoire. Pour les raisons citées précédemment, il n’est pas recommandé de configurer la VM avec plus d’un vCPU sauf si les applications sont développées spécifiquement ou si l’on souhaite faire tourner plusieurs applications dans sa VM. c. L’Hyper­Threading Cela consiste à créer deux instances logiques sur un processeur ou un cœ ur. Les tâches d’exécution sont ainsi parallélisées au sein même du cœ ur pour un traitement plus efficace. Les processeurs de type Intel Nehalem ont réintégré cette fonctionnalité bien qu’elle ait disparu avec les processeurs d’ancienne génération. Pour en savoir plus sur les résultats de performances, http://www.vmware.com/products/vmmark/results.html - 2-
vous © ENI Editions - All rigths reserved - Guillaume DUBOIS
pouvez consulter le site : 3. Dimensionnement Le licensing de vSphere 4 est basé sur le nombre de processeurs physiques et est vendu à partir de un processeur (contrairement à vi3 qui était vendu par lot de deux processeurs). ●
●
●
●
Même s’il est possible de déployer des serveurs Mono­processeur (un socket), ils sont peu utilisés aujourd’hui car ils n’offrent pas des taux de consolidation importants. Cependant ils peuvent être utilisés pour des besoins ponctuels ou pour des tests car leur coût est très faible. Les Bi­processeurs (deux sockets) sont aujourd’hui les plus largement répandus dans la virtualisation car ils offrent un très bon rapport prix/ratio de consolidation. Les Quadri­processeurs vendus ont le plus fort taux d’attachement à la virtualisation : plus de 20 % des serveurs en quadri­processeurs sont vendus pour des projets de virtualisation. Les Octo­processeurs et plus représentent en proportion un faible pourcentage de vente. Combien faut­il de VM par serveur ? Il est difficile de répondre à cette question car cela dépend fortement de l’environnement et des applications. Mais pour les serveurs de générations d’il y a trois ou quatre ans : ●
Si le taux d’utilisation CPU est inférieur à 15 % il est possible de mettre 3 ou 4 VM par cœ ur. ●
S’il est entre 15 % et 30 %, il est possible de mettre 2 ou 3 VM par cœur. ●
Si le taux d’utilisation du serveur est supérieur à 30 % et que le serveur est récent (moins de 2 ans d’âge) alors ce n’est peut­être pas un bon candidat pour la virtualisation. 4. Bonnes pratiques ●
●
●
●
●
Comme nous l’avons vu, le licensing se fait sur le nombre de processeurs physiques et comme ESX sait gérer un cœ ur comme un processeur physique, il faut privilégier les processeurs intégrant le plus grand nombre de cœ urs. Il est déconseillé de configurer les VM avec plus d’un vCPU, sauf en cas de préconisation de la part de l’éditeur du logiciel. Les processeurs plus rapides en fréquence améliorent les performances, cependant pour certaines charges de travail des caches plus importants permettent d’améliorer les performances. Il faut se renseigner auprès des éditeurs de logiciels. Il est important de faire un placement des machines virtuelles de façon cohérente en fonction des applications. Nous verrons en fin de ce chapitre, les composants les plus sollicités par les applications courantes. Certaines études ont montré que l’Hyper­Threading (cf. section L’Hyper­Threading) est utile et améliore les performances lorsqu’il y a beaucoup de VM avec de petites charges de travail. Lorsqu’il y a des VM avec de grosses charges de travail, il n’est pas judicieux d’activer l’Hyper­Threading qui n’apporte pas de gains de performances. © ENI Editions - All rigths reserved - Guillaume DUBOIS
- 3-