> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/fr/system-administration/cpu-overprovisioning-guide.md). # Surallocation CPU et planification des ressources ## 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 {% hint style="warning" %} **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 {% endhint %} ## 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 : ``` Ratio de surengagement = vCPU totaux attribués / cœurs physiques totaux ``` **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 | Type de charge de travail | Ratio | Remarques | | ------------------------------------------ | ------------ | -------------------------------------- | | 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 | {% hint style="success" %} **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. {% endhint %} ## 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 1. **Temps CPU prêt élevé :** VM attendant la disponibilité d’un CPU physique 2. **Performances incohérentes :** Applications qui fonctionnent bien parfois, mal à d’autres moments 3. **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 : ``` Cœurs disponibles = (Nœuds - 1) × cœurs par nœud vCPU utilisables = cœurs disponibles × ratio de surengagement cible ``` **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 {% hint style="warning" %} **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. {% endhint %} ## Bonnes pratiques ### Directives générales 1. **Surveillez avant d’allouer :** Comprenez les schémas réels d’utilisation du CPU avant d’ajouter de la capacité 2. **Dimensionnez correctement les VM :** Commencez avec moins de vCPU et augmentez selon les besoins 3. **Réservez de la marge :** Conservez 20 à 30 % de capacité disponible pour les pics et le basculement 4. **Utilisez les limites CPU avec parcimonie :** Elles empêchent les VM d’utiliser les ressources inactives disponibles ### Conception du cluster 1. **Taille de nœud cohérente :** Simplifie la planification de capacité 2. **Prévoyez N+1 :** Supposez toujours qu’un nœud sera indisponible 3. **Documentez les hypothèses :** Consignez vos objectifs de surengagement et vos raisons ### Configuration de la VM 1. **Adaptez les vCPU à la charge de travail :** Plus de vCPU ne signifie pas toujours de meilleures performances 2. **Tenez compte de NUMA :** Pour les grandes VM, gardez les vCPU dans les limites du nœud NUMA 3. **Testez les performances :** Mesurez avec des charges de travail réalistes ## Surveillance de l’état du CPU ### Métriques clés à surveiller | Métrique | Plage saine | Action si dépassé | | -------------------------- | -------------------------------- | ------------------------------------ | | 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 1. Accédez à **Infrastructure** > **Clusters** 2. Affichez les graphiques d’utilisation du CPU 3. Cliquez sur des nœuds individuels pour voir les métriques par nœud 4. 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](/run-the-platform/system-administration/clusters-overview.md). ## 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](/run-the-platform/system-administration/clusters-overview.md) - Comprendre l’architecture du cluster * [Options de configuration du cluster](/run-the-platform/system-administration/cluster-settings.md) - Toutes les options de cluster expliquées * [Bonnes pratiques VM](/run-the-platform/virtual-machines/vm-best-practices.md) - Recommandations pour la configuration des VM * [Création de machines virtuelles](/run-the-platform/virtual-machines/creating-vms.md) - Guide de création des VM * [Migrations à chaud](/run-the-platform/virtual-machines/live-migrations.md) - Déplacement des VM entre les nœuds --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/knowledge-base/fr/system-administration/cpu-overprovisioning-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.