2.6. Recommandations pour RHEL KVM sur les hôtes IBM zSystems
L'optimisation d'un environnement de serveurs virtuels KVM dépend fortement des charges de travail des serveurs virtuels et des ressources disponibles. La même action qui améliore les performances dans un environnement peut avoir des effets négatifs dans un autre. Trouver le meilleur équilibre pour un environnement particulier peut s'avérer difficile et implique souvent des expérimentations.
La section suivante présente quelques bonnes pratiques lors de l'utilisation d'OpenShift Container Platform avec RHEL KVM sur les environnements IBM zSystems et IBM® LinuxONE.
2.6.1. Utiliser plusieurs files d'attente pour les interfaces réseau VirtIO
Avec plusieurs unités centrales virtuelles, vous pouvez transférer des paquets en parallèle si vous prévoyez plusieurs files d'attente pour les paquets entrants et sortants. Utilisez l'attribut queues
de l'élément driver
pour configurer plusieurs files d'attente. Spécifiez un nombre entier d'au moins 2 qui ne dépasse pas le nombre de CPU virtuels du serveur virtuel.
L'exemple de spécification suivant configure deux files d'attente d'entrée et de sortie pour une interface réseau :
<interface type="direct"> <source network="net01"/> <model type="virtio"/> <driver ... queues="2"/> </interface>
Les files d'attente multiples sont conçues pour améliorer les performances d'une interface réseau, mais elles utilisent également des ressources de mémoire et d'unité centrale. Commencez par définir deux files d'attente pour les interfaces très fréquentées. Essayez ensuite de définir deux files d'attente pour les interfaces à faible trafic ou plus de deux files d'attente pour les interfaces très fréquentées.
2.6.2. Utiliser des threads d'E/S pour vos blocs virtuels
Pour que les périphériques de blocs virtuels utilisent des threads d'E/S, vous devez configurer un ou plusieurs threads d'E/S pour le serveur virtuel et chaque périphérique de bloc virtuel doit utiliser l'un de ces threads d'E/S.
L'exemple suivant indique que <iothreads>3</iothreads>
doit configurer trois threads d'E/S, avec les ID de threads décimaux consécutifs 1, 2 et 3. Le paramètre iothread="2"
spécifie l'élément du pilote de l'unité de disque qui doit utiliser le fil d'exécution d'E/S avec l'ID 2.
Exemple de spécification d'un fil d'E/S
... <domain> <iothreads>3</iothreads>1 ... <devices> ... <disk type="block" device="disk">2 <driver ... iothread="2"/> </disk> ... </devices> ... </domain>
Les threads peuvent augmenter les performances des opérations d'E/S pour les périphériques de disque, mais ils utilisent également de la mémoire et des ressources de l'unité centrale. Vous pouvez configurer plusieurs périphériques pour qu'ils utilisent le même thread. Le meilleur mappage des threads aux périphériques dépend des ressources disponibles et de la charge de travail.
Commencez par un petit nombre de fils d'entrée/sortie. Souvent, un seul thread d'E/S pour tous les périphériques de disque est suffisant. Ne configurez pas plus de threads que le nombre de CPU virtuels et ne configurez pas de threads inactifs.
Vous pouvez utiliser la commande virsh iothreadadd
pour ajouter des threads d'E/S avec des ID de threads spécifiques à un serveur virtuel en cours d'exécution.
2.6.3. Éviter les périphériques SCSI virtuels
Ne configurez les périphériques SCSI virtuels que si vous avez besoin d'adresser le périphérique par le biais d'interfaces spécifiques SCSI. Configurez l'espace disque en tant que périphériques de bloc virtuels plutôt qu'en tant que périphériques SCSI virtuels, indépendamment de la sauvegarde sur l'hôte.
Cependant, vous pouvez avoir besoin d'interfaces spécifiques SCSI pour :
- LUN d'un lecteur de bandes SCSI sur l'hôte.
- Un fichier ISO de DVD sur le système de fichiers de l'hôte qui est monté sur un lecteur de DVD virtuel.
2.6.4. Configurer la mise en cache du disque par l'invité
Configurez vos périphériques de disque pour que la mise en cache soit effectuée par l'invité et non par l'hôte.
Assurez-vous que l'élément pilote de l'unité de disque inclut les paramètres cache="none"
et io="native"
.
<disk type="block" device="disk"> <driver name="qemu" type="raw" cache="none" io="native" iothread="1"/> ... </disk>
2.6.5. Exclure le dispositif de ballon de mémoire
À moins que vous n'ayez besoin d'une taille de mémoire dynamique, ne définissez pas de périphérique de ballon de mémoire et assurez-vous que libvirt n'en crée pas un pour vous. Incluez le paramètre memballoon
en tant qu'enfant de l'élément devices dans votre fichier XML de configuration de domaine.
Vérifier la liste des profils actifs :
<memballoon model="none"/>
2.6.6. Ajuster l'algorithme de migration de l'unité centrale de l'ordonnanceur de l'hôte
Ne modifiez pas les paramètres de l'ordonnanceur si vous n'êtes pas un expert qui en comprend les implications. N'appliquez pas de modifications aux systèmes de production sans les avoir testées et avoir confirmé qu'elles ont l'effet escompté.
Le paramètre kernel.sched_migration_cost_ns
spécifie un intervalle de temps en nanosecondes. Après la dernière exécution d'une tâche, le cache de l'unité centrale est considéré comme ayant un contenu utile jusqu'à l'expiration de cet intervalle. L'augmentation de cet intervalle permet de réduire le nombre de migrations de tâches. La valeur par défaut est 500000 ns.
Si le temps d'inactivité du CPU est plus élevé que prévu lorsqu'il y a des processus exécutables, essayez de réduire cet intervalle. Si les tâches passent trop souvent d'un CPU ou d'un nœud à l'autre, essayez de l'augmenter.
Pour définir dynamiquement l'intervalle à 60000 ns, entrez la commande suivante :
# sysctl kernel.sched_migration_cost_ns=60000
Pour modifier de façon permanente la valeur de 60000 ns, ajoutez l'entrée suivante à /etc/sysctl.conf
:
kernel.sched_migration_cost_ns=60000
2.6.7. Désactiver le contrôleur cpuset cgroup
Ce paramètre ne s'applique qu'aux hôtes KVM dotés de cgroups version 1. Pour activer le hotplug du processeur sur l'hôte, désactivez le contrôleur cgroup.
Procédure
-
Ouvrez
/etc/libvirt/qemu.conf
avec l'éditeur de votre choix. -
Allez à la ligne
cgroup_controllers
. - Dupliquez la ligne entière et supprimez le premier signe numérique (#) de la copie.
Retirez l'entrée
cpuset
en procédant comme suit :cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]
Pour que le nouveau paramètre prenne effet, vous devez redémarrer le démon libvirtd :
- Arrêter toutes les machines virtuelles.
Exécutez la commande suivante :
# systemctl restart libvirtd
- Redémarrer les machines virtuelles.
Ce paramètre persiste lors des redémarrages de l'hôte.
2.6.8. Régler la période d'interrogation des CPU virtuels inactifs
Lorsqu'un processeur virtuel est inactif, KVM recherche les conditions de réveil du processeur virtuel avant d'allouer la ressource hôte. Vous pouvez spécifier l'intervalle de temps pendant lequel l'interrogation a lieu dans sysfs à l'adresse /sys/module/kvm/parameters/halt_poll_ns
. Pendant la durée spécifiée, l'interrogation réduit la latence de réveil de l'unité centrale virtuelle au détriment de l'utilisation des ressources. En fonction de la charge de travail, une durée d'interrogation plus longue ou plus courte peut être bénéfique. L'intervalle de temps est spécifié en nanosecondes. La valeur par défaut est de 50000 ns.
Pour optimiser la consommation de l'unité centrale, entrez une petite valeur ou écrivez 0 pour désactiver l'interrogation :
# echo 0 > /sys/module/kvm/paramètres/halt_poll_ns
Pour optimiser la latence, par exemple pour les charges de travail transactionnelles, saisissez une valeur élevée :
# echo 80000 > /sys/module/kvm/paramètres/halt_poll_ns
Ressources supplémentaires