Surallocation CPU et planification des ressources
Comprendre l’allocation CPU, les ratios de surengagement et les implications sur les performances dans VergeOS, y compris les ratios recommandés par type de charge de travail et les calculs de planification de capacité.
Vue d’ensemble
La surallocation de CPU (aussi appelée surengagement) vous permet d’allouer davantage de cœurs CPU virtuels aux charges de travail que vous n’avez de cœurs physiques disponibles. Ce guide explique comment VergeOS gère les ressources CPU, les implications de la surallocation et les bonnes pratiques de planification des capacités.
Fonctionnement de l’allocation CPU dans VergeOS
Cœurs virtuels vs cœurs physiques
Lorsque vous attribuez des vCPU à une VM, vous allouez des cœurs virtuels qui sont planifiés sur des cœurs CPU physiques. VergeOS ne réserve pas de cœurs physiques exclusivement aux VM ; il utilise plutôt un découpage temporel pour partager les ressources physiques.
Points clés :
Les vCPU ne sont pas épinglés par défaut à des cœurs physiques
Plusieurs vCPU provenant de différentes VM peuvent partager le même cœur physique
Le planificateur de l’hyperviseur gère l’allocation du temps CPU
Le paramètre « Max cores per machine »
Ce paramètre de cluster contrôle le nombre maximal de cœurs CPU pouvant être attribués à une seule charge de travail (VM, nœud de locataire ou service NAS).
Emplacement : Infrastructure > Clusters > [Nom du cluster] > Modifier
Contraintes critiques
Cette valeur devrait ne jamais dépasser le nombre total de cœurs physiques sur votre nœud le plus petit
Dans la plupart des cas, conservez-la dans un seul socket CPU pour des performances NUMA optimales
Les VM dépassant cette limite après un changement ne peuvent pas migrer tant que le nombre de cœurs n’a pas été réduit
Ratios de surengagement CPU
Qu’est-ce qu’un ratio de surengagement ?
Le ratio du total des vCPU attribués par rapport au total des cœurs physiques :
Exemple : Un cluster à 2 nœuds avec 32 cœurs chacun (64 au total) exécutant des VM avec 96 vCPU au total a un ratio de surengagement de 1,5:1.
Ratios recommandés par type de charge de travail
Charges de travail légères/de bureau
4:1 à 6:1
VM de bureau, serveurs de fichiers
Usage général mixte
2:1 à 4:1
Mélange d’entreprise typique
Serveurs de base de données/d’applications
1:1 à 2:1
Sensible aux performances
Calcul haute performance
1:1 ou moins
Charges de travail limitées par le CPU
Commencez prudemment
Commencez avec des ratios plus faibles et augmentez-les en fonction de la surveillance. Il est plus facile d’ajouter de la capacité que de se remettre de mauvaises performances.
Impacts sur les performances
Quand le surengagement fonctionne bien
Charges de travail par à-coups : VM qui connaissent des pics CPU occasionnels mais sont la plupart du temps inactives
Timing varié : Charges de travail qui culminent à des moments différents
Applications liées aux E/S : VM qui attendent davantage le disque ou le réseau que le CPU
Quand le surengagement pose problème
Charges de travail limitées par le CPU : Applications utilisant constamment 100 % du CPU
Applications sensibles à la latence : Systèmes temps réel, VoIP, trading
Demande simultanée : Toutes les VM ayant besoin du CPU au même moment
Signes de surengagement excessif
Temps CPU prêt élevé : VM attendant la disponibilité d’un CPU physique
Performances incohérentes : Applications qui fonctionnent bien parfois, mal à d’autres moments
Le système d’exploitation invité affiche un CPU élevé : Mais l’hyperviseur montre une utilisation plus faible
Planification des capacités
Calcul de la capacité CPU disponible
Pour un cluster avec redondance N+1 :
Exemple : Cluster à 4 nœuds, 32 cœurs chacun, ratio cible de 2:1
Disponibles : (4-1) × 32 = 96 cœurs
vCPU utilisables : 96 × 2 = 192 vCPU
Considérations relatives à la migration
Lorsqu’un nœud tombe en panne ou passe en maintenance :
Toutes les VM doivent tenir sur les nœuds restants
Chaque VM doit respecter le paramètre « Max cores per machine »
Les VM avec de nombreux vCPU peuvent se retrouver bloquées si aucun nœud unique ne peut les héberger
Prêt pour la migration
Si une VM possède 64 vCPU mais que vos nœuds n’ont que 32 cœurs, cette VM ne peuvent pas migrer lors d’événements de maintenance ou de panne. Conservez le nombre de cœurs des VM dans la capacité d’un seul nœud.
Bonnes pratiques
Directives générales
Surveillez avant d’allouer : Comprenez les schémas réels d’utilisation du CPU avant d’ajouter de la capacité
Dimensionnez correctement les VM : Commencez avec moins de vCPU et augmentez selon les besoins
Réservez de la marge : Conservez 20 à 30 % de capacité disponible pour les pics et le basculement
Utilisez les limites CPU avec parcimonie : Elles empêchent les VM d’utiliser les ressources inactives disponibles
Conception du cluster
Taille de nœud cohérente : Simplifie la planification de capacité
Prévoyez N+1 : Supposez toujours qu’un nœud sera indisponible
Documentez les hypothèses : Consignez vos objectifs de surengagement et vos raisons
Configuration de la VM
Adaptez les vCPU à la charge de travail : Plus de vCPU ne signifie pas toujours de meilleures performances
Tenez compte de NUMA : Pour les grandes VM, gardez les vCPU dans les limites du nœud NUMA
Testez les performances : Mesurez avec des charges de travail réalistes
Surveillance de l’état du CPU
Métriques clés à surveiller
Utilisation CPU du cluster
< 70 % en moyenne
Ajoutez des nœuds ou réduisez les VM
Utilisation CPU du nœud
< 80 % de manière soutenue
Vérifiez la répartition des VM
CPU de chaque VM
Varie selon la charge de travail
Redimensionnez ou enquêtez
Utilisation du tableau de bord VergeOS
Accédez à Infrastructure > Clusters
Affichez les graphiques d’utilisation du CPU
Cliquez sur des nœuds individuels pour voir les métriques par nœud
Vérifiez les statistiques CPU des VM dans le tableau de bord de chaque VM
Pour plus de détails sur la surveillance du cluster, voir Vue d’ensemble des clusters.
FAQ
Puis-je attribuer à une seule VM plus de vCPU que de cœurs physiques ?
Oui, mais c’est rarement avantageux. Une VM avec plus de vCPU que de cœurs physiques sur un nœud peut subir des retards de planification, car l’hyperviseur attend qu’un nombre suffisant de cœurs soient disponibles simultanément.
VergeOS prend-il en charge l’épinglage CPU ?
VergeOS ne prend pas en charge l’épinglage CPU (affinité). En interne, VergeOS utilise le planificateur Linux Completely Fair Scheduler (CFS) pour la planification du CPU. Chaque vCPU est mappé à un processus/fil Linux, et tous les threads vCPU partagent la même file d’exécution CFS. Le planificateur utilise une logique d’équité globale pour déterminer quel processus obtient du temps CPU et dans quel ordre.
Cette conception garantit une utilisation optimale des ressources et maintient la mobilité des VM pour la migration à chaud et le basculement. Lorsque vous surengagez les ressources CPU, vous partagez ce pool de cœurs physiques avec d’autres VM et locataires.
Quel impact cela a-t-il sur les licences logicielles ?
Certains logiciels (Oracle, SQL Server) sont licenciés par cœur physique ou par socket. La planification dynamique de VergeOS signifie que vous ne pouvez pas « partitionner fermement » les ressources CPU. Consultez les politiques de licence de virtualisation de votre éditeur de logiciel : beaucoup proposent des modèles de licence par vCPU ou par VM qui fonctionnent mieux avec les hyperviseurs modernes.
Et NUMA ?
Pour les VM avec de nombreux vCPU, VergeOS tente de conserver les allocations de mémoire et de CPU dans le même nœud NUMA lorsque c’est possible. Pour de meilleures performances NUMA, conservez un nombre de vCPU par VM inférieur ou égal au nombre de cœurs d’un seul socket.
Sujets connexes
Vue d’ensemble des clusters - Comprendre l’architecture du cluster
Options de configuration du cluster - Toutes les options de cluster expliquées
Bonnes pratiques VM - Recommandations pour la configuration des VM
Création de machines virtuelles - Guide de création des VM
Migrations à chaud - Déplacement des VM entre les nœuds
Mis à jour
Ce contenu vous a-t-il été utile ?