Considérations sur le CPU et la mémoire

Types de CPU

Le réglage du type de CPU vous permet de choisir en fonction de la génération et des fonctionnalités du CPU, garantissant un fonctionnement cohérent même si l’infrastructure cloud privée utilise différents CPU. Cependant, la migration en direct entre les CPU Intel et AMD n’est pas garantie.

Sélectionner « host » en bas du menu déroulant utilisera le même CPU que l’hôte physique, maximisant l’efficacité. Cependant, cela empêche la migration en direct entre des hôtes de différentes générations, ce qui peut poser problème si de nouvelles unités HRPC sont ajoutées au centre de données virtuel à l’avenir.

La plupart des systèmes d’exploitation modernes fonctionnent avec x86-64-v2, qui prend en charge des ensembles d’instructions tels que SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT et CMPXCHG16B. L’option x86-64-v2-aes inclut les instructions de chiffrement AES, permettant des performances plus rapides pour les logiciels de chiffrement.

Choisir x86-64-v3 permet l’utilisation des instructions AVX et AVX2, tandis que x86-64-v4 ajoute la prise en charge des instructions AVX-512.

Tous les modèles de cloud privé HRPC à partir de 6Gt prennent en charge x86-64-v4.

Le tableau suivant résume ces informations :

Processeur	x86-64-v1	x86-64-v2	x86-64-v2-aes	x86-64-v3	x86-64-v4
Instructions prises en charge	Ensemble d’instructions de base x86-64	SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B	x86-64-v2 + AES	AVX, AVX2, BMI1, BMI2, FMA, MOVBE	Famille AVX-512 (AVX-512F, AVX-512CD, AVX-512DQ, AVX-512BW, AVX-512VL, etc.)
Intel Xeon	Série Intel Xeon 3000/5000/7000 (1re génération)	Série Intel Xeon 5500 (Nehalem) et ultérieure	Série Intel Xeon 5600 (Westmere) et ultérieure	Intel Xeon E3 v3 (Haswell) et ultérieur, Intel Xeon E5/E7 v3 (Haswell-EP/EX) et ultérieur, Processeurs Intel Xeon Scalable 1re génération (Skylake-SP) et ultérieur	Processeurs Intel Xeon Scalable 2e génération (Cascade Lake-SP) et ultérieur, Processeurs Intel Xeon Scalable 3e génération (Ice Lake-SP)
AMD Opteron	Série AMD Opteron 100/200/800 (SledgeHammer)	Série AMD Opteron 4200/6200 (Bulldozer) et ultérieure	Série AMD Opteron 4300/6300 (Piledriver) et ultérieure	Non applicable	Non applicable
AMD EPYC	Non applicable	1re génération AMD EPYC (Naples)	1re génération AMD EPYC (Naples)	Série AMD EPYC 7002 (Rome) et ultérieure	Série AMD EPYC 7003 (Milan) et ultérieure

Gestion de la mémoire KVM et pilote de Ballooning

En bref, le pilote de Ballooning est inutile dans l’infrastructure HRPC et il est recommandé de le désactiver.

Dans KVM, définir la valeur « Mémoire minimale » égale à la valeur « Mémoire » semble créer une allocation de mémoire fixe. Cependant, en raison de la nature de la gestion de la mémoire sous Linux, la mémoire allouée et l’utilisation réelle diffèrent. Le système réserve de la mémoire au démarrage, mais elle n’est activement utilisée que lorsque des données y sont écrites, rendant l’utilisation de la mémoire effectivement dynamique.

Cela peut être observé dans la section « Utilisation de la mémoire » du résumé de l’hôte ou de la machine virtuelle. Par exemple, une machine virtuelle à laquelle 32 Go de mémoire sont attribués peut n’utiliser que 13,56 Go en réalité.

Dans un système Proxmox VE typique, des machines virtuelles peuvent être créées tant qu’il y a de la mémoire disponible. Cependant, si l’« Utilisation de la mémoire » affichée semble faible, les administrateurs peuvent allouer plus de mémoire que ce qui est physiquement disponible, entraînant un surengagement de mémoire. Lorsque les machines virtuelles demandent soudainement plus de mémoire, cela peut provoquer une instabilité, déclenchant potentiellement le tueur de mémoire insuffisante dans le système d’exploitation de l’hôte, ce qui peut interrompre de manière aléatoire des processus système critiques.

HRPC 6Gf est conçu pour une utilisation en entreprise avec un accent sur l’isolation, garantissant que des machines virtuelles ne peuvent pas être créées au-delà de la capacité de mémoire disponible.

Si la machine hôte manque de mémoire et que le dispositif de Ballooning est activé, le pilote de Ballooning force le système d’exploitation invité à libérer de la mémoire inutile (par exemple, les caches de disque, les pages modifiées), la restituant au système d’exploitation hôte. Ce processus augmente la charge du CPU et les opérations d’E/S, entraînant des retards et une instabilité, en particulier dans les systèmes à haute disponibilité (HA) sensibles à la latence.

Comme mentionné précédemment, l’hyperviseur personnalisé dans HRPC 6Gf empêche la création inutile de machines virtuelles, rendant le dispositif de Ballooning largement inutile dans cet environnement.